[opensuse] Script fails for unknown reason
Hi list, This is part of a script to manage accounts of a vsftpd server It's called after an account is added, deleted or when a password has been changed. ftpStat () { /sbin/checkproc /usr/sbin/vsftpd; } restart_srv() { /etc/init.d/vsftpd restart sleep 5 rep=0 until ftpStat ; do /etc/init.d/vsftpd start sleep 5 rep=$((rep +=1)) if [ $((rep)) -ge 5 ]; then echo "There is something wrong with the FTP service.\ Please call the FTP admin" exit 1 fi done echo "The FTP server daemon has been restarted."; } The check to see if the server really has restarted is added because '/etc/init.d/vsftpd restart' would sometimes stop the server, but not start again appearently (I got calls that the server wasn't available after someone added an account). Weirdly enough, despite this check, sometimes it still happens that the service doesn't restart, but only on an openSUSE10.0 install with vsftpd-2.0.3-6 When I use the management script at home, on openSUSE 10.2 and with vsftpd-2.0.5-24 the restart always succeeds the first time without a hitch. The users can only sudo this one script btw, so they can not stop the service intentionally, and there are no errors or warnings in the logs when the service stopped. As far as I can see, this function is pretty foolproof, and should always exit with the service running, but nonetheless, something breaks (sometimes), and I have no clue why or what. Does anyone here see something wrong with this script that I don't? Cheers. Theo -- Theo v. Werkhoven Registered Linux user# 99872 http://counter.li.org ICBM 52 13 26N , 4 29 47E. + ICQ: 277217131 SUSE 10.2 + Jabber: muadib@jabber.xs4all.nl Kernel 2.6.20 + See headers for PGP/GPG info. Claimer: any email I receive will become my property. Disclaimers do not apply. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Theo v. Werkhoven wrote:
Hi list,
This is part of a script to manage accounts of a vsftpd server It's called after an account is added, deleted or when a password has been changed.
It's not immediately apparent to me why the script sometimes fails, but I've been running vsftpd from xinetd for years on a busy site, so this sort of thing is not needed. Any particular reason you need to run it standalone? Joe -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Thu, 13 Sep 2007, by joe@tmsusa.com:
Theo v. Werkhoven wrote:
Hi list,
This is part of a script to manage accounts of a vsftpd server It's called after an account is added, deleted or when a password has been changed.
It's not immediately apparent to me why the script sometimes fails, but I've been running vsftpd from xinetd for years on a busy site, so this sort of thing is not needed. Any particular reason you need to run it standalone?
There's no reason not to. (x)inetd is usefull when the resources are limited, and when it's better to have a single process listening for incoming connections, but in my server there are plenty resources for a stand-alone FTP server and the other services too (openVPN, sftp, ssh, Postfix), so why would I make it difficult with secondary xinetd process? Anyway, this has nothing to do with the problem. Tnx, Theo -- Theo v. Werkhoven Registered Linux user# 99872 http://counter.li.org ICBM 52 13 26N , 4 29 47E. + ICQ: 277217131 SUSE 10.2 + Jabber: muadib@jabber.xs4all.nl Kernel 2.6.20 + See headers for PGP/GPG info. Claimer: any email I receive will become my property. Disclaimers do not apply. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Theo v. Werkhoven wrote:
Thu, 13 Sep 2007, by joe@tmsusa.com:
Hi list,
This is part of a script to manage accounts of a vsftpd server It's called after an account is added, deleted or when a password has been changed. It's not immediately apparent to me why the script sometimes fails, but I've been running vsftpd from xinetd for years on a busy site, so this sort of
Theo v. Werkhoven wrote: thing is not needed. Any particular reason you need to run it standalone?
There's no reason not to. (x)inetd is usefull when the resources are limited, and when it's better to have a single process listening for incoming connections, but in my server there are plenty resources for a stand-alone FTP server and the other services too (openVPN, sftp, ssh, Postfix), so why would I make it difficult with secondary xinetd process? Anyway, this has nothing to do with the problem.
It has everything to do with the problem - if you run vsftpd from xinetd there is no need to manually restart it when adding/deleting/changing user accounts. In fact that's one of the main reasons we switched to xinetd. But, that doesn't answer your question, so I will respectfully bow out of the discussion now. Joe -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Thursday 13 September 2007 23:38:37 joe wrote:
It has everything to do with the problem - if you run vsftpd from xinetd there is no need to manually restart it when adding/deleting/changing user accounts. In fact that's one of the main reasons we switched to xinetd.
This still begs the question vsftpd uses pam, and pam doesn't cache user info, and since it's external to vsftpd, it literally can't cache it. Just for the hell of it, I just tested it, and it worked perfectly with new users, and with changed passwords, without any restart at all necessary -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Anders Johansson wrote:
On Thursday 13 September 2007 23:38:37 joe wrote:
It has everything to do with the problem - if you run vsftpd from xinetd there is no need to manually restart it when adding/deleting/changing user accounts. In fact that's one of the main reasons we switched to xinetd.
This still begs the question
vsftpd uses pam, and pam doesn't cache user info, and since it's external to vsftpd, it literally can't cache it.
Just for the hell of it, I just tested it, and it worked perfectly with new users, and with changed passwords, without any restart at all necessary
Are you running it standalone? Joe -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Friday 14 September 2007 00:01:36 joe wrote:
Anders Johansson wrote:
On Thursday 13 September 2007 23:38:37 joe wrote:
It has everything to do with the problem - if you run vsftpd from xinetd there is no need to manually restart it when adding/deleting/changing user accounts. In fact that's one of the main reasons we switched to xinetd.
This still begs the question
vsftpd uses pam, and pam doesn't cache user info, and since it's external to vsftpd, it literally can't cache it.
Just for the hell of it, I just tested it, and it worked perfectly with new users, and with changed passwords, without any restart at all necessary
Are you running it standalone?
Yes, otherwise it would be restarted (as you said yourself) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Fri, 14 Sep 2007, by ajohansson@t-online.de:
On Friday 14 September 2007 00:01:36 joe wrote:
Anders Johansson wrote:
On Thursday 13 September 2007 23:38:37 joe wrote:
It has everything to do with the problem - if you run vsftpd from xinetd there is no need to manually restart it when adding/deleting/changing user accounts. In fact that's one of the main reasons we switched to xinetd.
This still begs the question
vsftpd uses pam, and pam doesn't cache user info, and since it's external to vsftpd, it literally can't cache it.
Just for the hell of it, I just tested it, and it worked perfectly with new users, and with changed passwords, without any restart at all necessary
Are you running it standalone?
Yes, otherwise it would be restarted (as you said yourself)
And with virtual users in a Berkeley database, with pam_userdb as I am? as far as I know, vsftpd needs to be made aware of a change in the database file that pam_userdb uses, by restarting. For users in /etc/passwd this is not necessary. But to make sure, I'll try to change accounts without restarting. Theo -- Theo v. Werkhoven Registered Linux user# 99872 http://counter.li.org ICBM 52 13 26N , 4 29 47E. + ICQ: 277217131 SUSE 10.2 + Jabber: muadib@jabber.xs4all.nl Kernel 2.6.20 + See headers for PGP/GPG info. Claimer: any email I receive will become my property. Disclaimers do not apply. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Friday 14 September 2007 00:26:25 Theo v. Werkhoven wrote:
And with virtual users in a Berkeley database, with pam_userdb as I am? as far as I know, vsftpd needs to be made aware of a change in the database file that pam_userdb uses, by restarting.
vsftpd doesn't know anything about pam_userdb. It just calls libpam, which reads /etc/pam.d/vsftpd, and if you happen to have pam_userdb in there, it will dlopen() it, call the proper functions, and then dlclose() it. If anything at all was cached there, between pam calls, I would be highly surprised. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Anders Johansson wrote:
On Friday 14 September 2007 00:01:36 joe wrote:
Anders Johansson wrote:
On Thursday 13 September 2007 23:38:37 joe wrote:
It has everything to do with the problem - if you run vsftpd from xinetd there is no need to manually restart it when adding/deleting/changing user accounts. In fact that's one of the main reasons we switched to xinetd. This still begs the question
vsftpd uses pam, and pam doesn't cache user info, and since it's external to vsftpd, it literally can't cache it.
Just for the hell of it, I just tested it, and it worked perfectly with new users, and with changed passwords, without any restart at all necessary Are you running it standalone?
Yes, otherwise it would be restarted (as you said yourself)
OK, that was just a sanity check. Perhaps my experience is dated, but when I was running standalone some years ago I had to restart the ftp server whenever making any type of user account change. Joe -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Thursday 13 September 2007 22:18:17 Theo v. Werkhoven wrote:
Weirdly enough, despite this check, sometimes it still happens that the service doesn't restart, but only on an openSUSE10.0 install with vsftpd-2.0.3-6 When I use the management script at home, on openSUSE 10.2 and with vsftpd-2.0.5-24 the restart always succeeds the first time without a hitch.
Off the top of my head, could it be that port 21 is still in use (by an open session perhaps) so it can't bind to the port? But is this really necessary just because an account is added, deleted or changed? vsftpd uses pam, so it should get updated properly just like any other service -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Thu, 13 Sep 2007, by ajohansson@t-online.de:
On Thursday 13 September 2007 22:18:17 Theo v. Werkhoven wrote:
Weirdly enough, despite this check, sometimes it still happens that the service doesn't restart, but only on an openSUSE10.0 install with vsftpd-2.0.3-6 When I use the management script at home, on openSUSE 10.2 and with vsftpd-2.0.5-24 the restart always succeeds the first time without a hitch.
Off the top of my head, could it be that port 21 is still in use (by an open session perhaps) so it can't bind to the port?
Not likely. And there would be an error in the logs if it was the case afaik.
But is this really necessary just because an account is added, deleted or changed? vsftpd uses pam, so it should get updated properly just like any other service
You know what? You were right.. I thought I read somewhere that a restart was needed, but it isn't, a change in the db is implemented immediate. That saves me yet another headache. Thanks Anders and Joe, have a good weekend. Theo -- Theo v. Werkhoven Registered Linux user# 99872 http://counter.li.org ICBM 52 13 26N , 4 29 47E. + ICQ: 277217131 SUSE 10.2 + Jabber: muadib@jabber.xs4all.nl Kernel 2.6.20 + See headers for PGP/GPG info. Claimer: any email I receive will become my property. Disclaimers do not apply. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (3)
-
Anders Johansson -
joe -
Theo v. Werkhoven