hello, when i connect with the gnu-midnight-commander (mc) to my zope-ftp-port (8021), zope crashes if i submit a wrong login. this happens on linux (zope 2.4.3, mc 4.5.51) and freebsd (zope 2.4.1, mc 4.5.54), so i think it must be a problem of zope... ftping with a normal client works well... what's wrong with zope and midnight-commander? thanx4hlp maik.
On Tue, 8 Jan 2002, Maik Jablonski wrote:
when i connect with the gnu-midnight-commander (mc) to my zope-ftp-port (8021), zope crashes if i submit a wrong login.
this happens on linux (zope 2.4.3, mc 4.5.51) and freebsd (zope 2.4.1, mc 4.5.54), so i think it must be a problem of zope...
ftping with a normal client works well...
what's wrong with zope and midnight-commander? I have no problem under Debain GNU/Linux Woody with about the same version numbers (mc 4.5.55, zope 2.4.2).
By the way I stoped using mc-ftp because Kernel ftpfs is much more transparent and works great! Kind regards Andreas.
when i connect with the gnu-midnight-commander (mc) to my zope-ftp-port (8021), zope crashes if i submit a wrong login.
this happens on linux (zope 2.4.3, mc 4.5.51) and freebsd (zope 2.4.1, mc 4.5.54), so i think it must be a problem of zope...
ftping with a normal client works well...
what's wrong with zope and midnight-commander?
I have no problem under Debain GNU/Linux Woody with about the same version numbers (mc 4.5.55, zope 2.4.2).
I can confirm this, it's been bothering me for a few months now. It looks like there's something wrong in both MC and Zope. I am cross-posting to the MC list too ( http://mail.gnome.org/mailman/listinfo/mc ). I'm using MC 4.5.55 and Zope 2.4.3, and this has been going on at least from MC 4.5.51 and Zope 2.3.1 , on Linux Slackware 7.1 and now 8.0 .
By the way I stoped using mc-ftp because Kernel ftpfs is much more transparent and works great!
How does one enable this? I cannot see it in /proc/filesystems . -- "Mozilla will be around long after nobody can remember just quite what Internet Explorer actually used to be." AirLace on Slashdot Nicola Larosa - nico@tekNico.net
----- Original Message ----- From: "Nicola Larosa" <nico@tekNico.net> To: "Zope user list" <zope@zope.org> Cc: "MC list" <mc@gnome.org> Sent: Thursday, January 10, 2002 13:44 Subject: Re: [Zope] mc-ftp crashes zope
when i connect with the gnu-midnight-commander (mc) to my zope-ftp-port (8021), zope crashes if i submit a wrong login.
this happens on linux (zope 2.4.3, mc 4.5.51) and freebsd (zope 2.4.1, mc 4.5.54), so i think it must be a problem of zope...
ftping with a normal client works well...
what's wrong with zope and midnight-commander?
I have no problem under Debain GNU/Linux Woody with about the same version numbers (mc 4.5.55, zope 2.4.2).
I can confirm this, it's been bothering me for a few months now. It looks like there's something wrong in both MC and Zope. I am cross-posting to the MC list too ( http://mail.gnome.org/mailman/listinfo/mc ).
I'm using MC 4.5.55 and Zope 2.4.3, and this has been going on at least from MC 4.5.51 and Zope 2.3.1 , on Linux Slackware 7.1 and now 8.0 .
Is this behaviour reproducable ? Any core dumps or entries in the stupid logfile ? - aj
Is this behaviour reproducable?
Not deterministically, it only happens sometimes, cannot isolate a sequence of actions that make it happen predictably.
Any core dumps
None in /var/zope/var, where else should I look for them?
or entries in the stupid logfile?
Is that the Z2.log file, or do I need to enable it some other way? I tried now, it did not crash, I put in a wrong password, but the Z2.log file says so: 127.0.0.13205 ==> 220 altair FTP server (Medusa Async V1.17.16.2 [experimental]) ready. 127.0.0.13205 <== USER admin 127.0.0.13205 ==> 331 Password required. 127.0.0.13205 <== PASS <password> 127.0.0.13205 ==> 230 Login successful. 127.0.0.13205 <== PWD 127.0.0.13205 ==> 257 "/" is the current directory. 127.0.0.13205 <== PASV 127.0.0.13205 ==> 227 Entering Passive Mode (127,0,0,1,12,134) 127.0.0.13205 <== TYPE A 127.0.0.13205 ==> 200 Type set to ASCII. 127.0.0.13205 <== LIST -la /. 127.0.0.13205 ==> 530 Unauthorized. 127.0.0.13205 <== CWD / 127.0.0.13205 ==> 530 Unauthorized. 127.0.0.13205 <== CWD / 127.0.0.13205 ==> 530 Unauthorized. 127.0.0.13205 <== CWD / 127.0.0.13205 ==> 530 Unauthorized. 127.0.0.13205 <== CWD / 127.0.0.13205 ==> 530 Unauthorized. Maybe MC does not recognize that the login was *not* succesful? -- "Mozilla will be around long after nobody can remember just quite what Internet Explorer actually used to be." AirLace on Slashdot Nicola Larosa - nico@tekNico.net
On Sat, Jan 12, 2002 at 04:16:02PM +0100, Nicola Larosa wrote:
Is this behaviour reproducable?
Not deterministically, it only happens sometimes, cannot isolate a sequence of actions that make it happen predictably.
Any core dumps
None in /var/zope/var, where else should I look for them?
or entries in the stupid logfile?
Is that the Z2.log file, or do I need to enable it some other way?
I tried now, it did not crash, I put in a wrong password, but the Z2.log file says so:
127.0.0.13205 ==> 220 altair FTP server (Medusa Async V1.17.16.2 [experimental]) ready. 127.0.0.13205 <== USER admin 127.0.0.13205 ==> 331 Password required. 127.0.0.13205 <== PASS <password> 127.0.0.13205 ==> 230 Login successful. 127.0.0.13205 <== PWD 127.0.0.13205 ==> 257 "/" is the current directory. 127.0.0.13205 <== PASV 127.0.0.13205 ==> 227 Entering Passive Mode (127,0,0,1,12,134) 127.0.0.13205 <== TYPE A 127.0.0.13205 ==> 200 Type set to ASCII. 127.0.0.13205 <== LIST -la /. 127.0.0.13205 ==> 530 Unauthorized. 127.0.0.13205 <== CWD / 127.0.0.13205 ==> 530 Unauthorized. 127.0.0.13205 <== CWD / 127.0.0.13205 ==> 530 Unauthorized. 127.0.0.13205 <== CWD / 127.0.0.13205 ==> 530 Unauthorized. 127.0.0.13205 <== CWD / 127.0.0.13205 ==> 530 Unauthorized.
Initial logins are *always* successful. The security checks are performed for every single command as "ls" in your example. This explains why you receive Unauthorized. Andreas
Hi, you should also enable loging in mc as well for starters. -l file Save the ftpfs dialog with the server in file. Ciao, Martin
you should also enable loging in mc as well for starters.
-l file Save the ftpfs dialog with the server in file.
Good idea, I'm going to do that as well. -- "Mozilla will be around long after nobody can remember just quite what Internet Explorer actually used to be." AirLace on Slashdot Nicola Larosa - nico@tekNico.net
Hi, I have done a navigation tree similar to what the zope management screen has. I have a tree of objects the user may navigate to. At the left he sees the content of the objects, at the right he sees a <dtml-tree> of all the folders and pages. Now, unlike the management screen, I do not want to use frames. So what I do currently is to include a special dtml-method (which contains nothing but the tree tag) in every page via <dtml-var ...> Everything is fine, except that after every click to the tree, all the nodes colapse again. This is not exactly the behaviour I would like to see. I would want to keep the state of the tree-tag. It has probably s.th. to do with me not using frames and the tree tag tracking it's state via the url it is contained in as key. Now, how (other than using frames) can I overcome this problem? many tia, Andreas
Silly me. I just found the solution. For those interested, I had to use the special "id" attribute of the dtml-tree tag. Andreas
Hi again, How can I find the real container of a given dtml-method. <dtml-var expr="aq_parent"> only gives me the aquired parent, which is not always what i want. I would like to know the folder where the dtml-method I am in is actually stored. many tia, Andreas
Andreas Leitner writes:
How can I find the real container of a given dtml-method. <dtml-var expr="aq_parent"> only gives me the aquired parent, which is not always what i want. I would like to know the folder where the dtml-method I am in is actually stored. You must use an External Method (or other file system based code or XXXPythonScript). There, you can use:
object.aq_inner.aq_parent This gives you the "object"s container. Dieter
On Mon, 2002-01-14 at 19:57, Dieter Maurer wrote:
Andreas Leitner writes:
How can I find the real container of a given dtml-method. <dtml-var expr="aq_parent"> only gives me the aquired parent, which is not always what i want. I would like to know the folder where the dtml-method I am in is actually stored. You must use an External Method (or other file system based code or XXXPythonScript). There, you can use:
object.aq_inner.aq_parent
This gives you the "object"s container.
I see. It is a bit confusing for me to know what attributes and methods work where (dtml, Product, external-method). I cannot really seem to find a complete API reference. Does it exist? The API in the appendix of the Zope book seems to ignore some pretty interesting details (like I have not found anything with "aq_" in there) Or even better, is there some way to introspect the current namespace? For example I would like to be able to print out all methods and variables accessible for a certain dtml-method/script/Product. Or am I missing something obvious? tia, Andreas
Andreas Leitner writes:
.... It is a bit confusing for me to know what attributes and methods work where (dtml, Product, external-method). I cannot really seem to find a complete API reference. Does it exist? It would be a monster, and you probably would not read it ;-)
... Or even better, is there some way to introspect the current namespace? DocFinder goes a bit along this route
<http://www.dieter.handshake.de/pyprojects/zope> It would not tell you about "aq_*" attributes because in its current form it only looks at class attributes. You may extend it, if you like... Dieter
Nicola Larosa writes:
Is this behaviour reproducable?
Not deterministically, it only happens sometimes, cannot isolate a sequence of actions that make it happen predictably.
Any core dumps
None in /var/zope/var, where else should I look for them? The are probably in "/var/zope".
But be warned, many Linux distributions disable "core" writing. You need to reenable them. Look at the "ulimit" internal bash command for details. Dieter
But be warned, many Linux distributions disable "core" writing. You need to reenable them. Look at the "ulimit" internal bash command for details.
You are right, "ulimit -c" gave 0 (zero). I've now put "ulimit -c unlimited" in my /etc/profile . But what do I do when I have those core dumps? -- "Mozilla will be around long after nobody can remember just quite what Internet Explorer actually used to be." AirLace on Slashdot Nicola Larosa - nico@tekNico.net
----- Original Message ----- From: "Nicola Larosa" <nico@tekNico.net> To: "Dieter Maurer" <dieter@handshake.de> Cc: "Andreas Jung" <andreas@andreas-jung.com>; "Zope user list" <zope@zope.org>; "MC list" <mc@gnome.org> Sent: Sunday, January 13, 2002 08:46 Subject: Re: [Zope] mc-ftp crashes zope
But be warned, many Linux distributions disable "core" writing. You need to reenable them. Look at the "ulimit" internal bash command for details.
You are right, "ulimit -c" gave 0 (zero).
I've now put "ulimit -c unlimited" in my /etc/profile . But what do I do when I have those core dumps?
Try to use gdb: "gdb python core" and then type "bt" or "where". This should output a traceback and show where the crash occured. - aj
On Thu, 10 Jan 2002, Nicola Larosa wrote:
By the way I stoped using mc-ftp because Kernel ftpfs is much more transparent and works great!
How does one enable this? I cannot see it in /proc/filesystems .
http://planetmirror.com/pub/sourceforge/ftpfs/ I just installed the Debian packages compiled the module - works great! Kind regards Andreas.
participants (8)
-
Andreas Jung -
Andreas Jung -
Andreas Leitner -
Dieter Maurer -
Maik Jablonski -
Martin Bialasinski -
Nicola Larosa -
Tille, Andreas