Bug 753365

(In reply to comment #0)
> Description of problem:
> The systemd unit file for vsftpd in F16 is odd in many ways and somewhat buggy:
> 
> Issue #1: Badly chosen service type
> "Type=oneshot" is useful for services that perform one-time initialization and
> do not fork off daemons, such as iptables. This is clearly not the case of
> vsftpd.
> The process started by the ExecStart command is not the main process of the
> service, because vsftpd forks. The type should be "forking" then. I suspect
> "RemainAfterExit=yes" is currently used as a workaround for the problems caused
> by the badly chosen type. It too is inappropriate for a daemon.

I taken that one on me the answer to the rest of your comments can be found in bug 719434...

Created attachment 533307 [details]
New and improved unit =)

Just drop in that one and fix the other unit's accordingly and as I had mentioned on the previous bug report ( comment 5 )the shipped templates can just act as addons for those that want to run more then one instance while having the vsftpd.service will keep upgrade paths along with service foo start backwards compatability...

*** Bug 753665 has been marked as a duplicate of this bug. ***

I couldn't get vsftpd to start at boot time either.  I just followed the
instructions under bug 753665 and that seems to have fixed it.  Then earlier
I couldn't get vsftpd to read home directories, and someone gave me an
incantation to fix that.

I'm dismayed that system administration is getting more arcane and difficult
as time goes on and new releases come out.  I've been with Linux for a long
time, and it just keeps getting more complicated without much improving
my ability to get my work done.  Sometimes we get new tools that make
system administration easier, and then things happen like the switch to
systemd that set me way back.  It shouldn't be this hard to set up an
ftpd server on my workstation.

vsftpd-2.3.4-6.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/vsftpd-2.3.4-6.fc16

I confirm the existence of this bug.

There is also a documentation error:

Section 15.2.4 of the Fedora 16 System Administrators Guide states that to start the vsfpd server, issue the command (as root) 'systemctl start vsftpd.service'. There are companion restart and stop commands.

The start command results in the following error: 'Failed to issue method call: Unit vsftpd.service failed to load: No such file or directory. See system logs and 'systemctl status vsftpd.service' for details.'

This appears to be a regression from fc-15 where vsftpd seemed to work fine.

There appear to be similar errors attempting to use the nfs server as well.

Try the update ( which was mentioned in comment 5 ) 

http://koji.fedoraproject.org/koji/buildinfo?buildID=274170

Works just fine there 

# for i in start status restart status stop status; do systemctl $i vsftpd.service; done 
vsftpd.service - Vsftpd ftp daemon
	  Loaded: loaded (/lib/systemd/system/vsftpd.service; disabled)
	  Active: active (running) since Tue, 15 Nov 2011 18:33:48 +0000; 38ms ago
	 Process: 17985 ExecStart=/usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf (code=exited, status=0/SUCCESS)
	Main PID: 17986 (vsftpd)
	  CGroup: name=systemd:/system/vsftpd.service
		  └ 17986 /usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf
vsftpd.service - Vsftpd ftp daemon
	  Loaded: loaded (/lib/systemd/system/vsftpd.service; disabled)
	  Active: active (running) since Tue, 15 Nov 2011 18:33:48 +0000; 20ms ago
	 Process: 17991 ExecStart=/usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf (code=exited, status=0/SUCCESS)
	Main PID: 17992 (vsftpd)
	  CGroup: name=systemd:/system/vsftpd.service
		  └ 17992 /usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf
vsftpd.service - Vsftpd ftp daemon
	  Loaded: loaded (/lib/systemd/system/vsftpd.service; disabled)
	  Active: inactive (dead) since Tue, 15 Nov 2011 18:33:48 +0000; 54ms ago
	 Process: 17991 ExecStart=/usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf (code=exited, status=0/SUCCESS)
	Main PID: 17992 (code=killed, signal=TERM)
	  CGroup: name=systemd:/system/vsftpd.service

Package vsftpd-2.3.4-6.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing vsftpd-2.3.4-6.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2011-15986
then log in and leave karma (feedback).

Response to comment 7:

Your recommendation works as follows. Thanks.

download the updates you recommended.

change to the directory of the download
command: su -c 'yum install vsftpd-2.3.4-6.fc16.x86_64.rpm'
su -c 'yum install vsftpd-sysvinit-2.3.4-6.fc16.x86_64.rpm'
su -c 'yum install vsftpd-debuginfo-2.3.4-6.fc16.x86_64.rpm'

Start the vsftpd service:
su -c systemctl start vsftpd.service

This works fine. It is possible to use the companion commands -- stop and restart as well.

There is still a problem, likely involving interaction with 'pluggable authentication modules'.

Anonymous ftp works.

It is not possible, however to log in with a user account, any adjustments in the files /etc/vsftpd/ directory notwithstanding. (Refer to Fedora 16 System Administrators Guide, Chapter 15.2.3.).

Any attempt to log in from either localhost (127.0.0.1) or from a remote client results in an error: 530 Login incorrect.
Login failed.

Response to Comment 8

Doesn't work yet. I haven't given the file to make its way to the repository yet. The instruction in Comment 7 seems to work relative to installing and running vsftpd as noted above.

Logging in under a user account still does not work. It worked in fc-15 server.

Thanks for all of your help.

Jiří,
thanks for putting the vsftpd.service unit into the package. May I suggest though that you also add a RPM scriptlet that would enable the new unit if the user previously had the vsftpd instance enabled? Some users may have already figured it out how to enable vsftpd in F16 GA and this update will make it disabled again. It probably does not make sense to try to migrate other instances of the template, but migrating at least the typical one should cover the most users.
Or at the very least, please add a warning note in the Bodhi description that manual enablement of the service is necessary after the update (systemctl enable vsftpd.service).

Another option would be to keep shipping the template vsftpd@.service (with the fixed Type=..., etc.) in the package in addition to the plain vsftpd.service. That way the users who already used the template in F16 GA can keep using it if they like. And don't touch vsftpd@.service in the scriptlets at all, it would be for manual handling only.

Re. FTP not working with user accounts in comment #9, this is another known bug - see https://bugzilla.redhat.com/show_bug.cgi?id=752827 for more info.

Assuming your default shell is bash, then the quickest fix is to add the line "/bin/bash" to the end of "/etc/shells" if it's not already present, or if you don't feel happy editing config files by hand run the following command:

sudo echo /bin/bash >> /etc/shells

A pending update to the bash package should fix this for good.

Response to Comment 12
Works! 
Thanks so much for your help.

vsftpd-2.3.4-6.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

I have been experiencing the same problem. when i opened /etc/shells to add /bin/bash at the end of the file i noticed that the last line read /bin/dash made the change. still get the 530 error

Is adding /bin/bash to the /etc/shells just a quick fix for error: 530 Login incorrect.

Is there a permanent fix for this.

The fix is imho a bit too simplistic.  Older System V init scripts did support running multiple instances of vsftpd, one for each /etc/vsftpd/vsftpd*.conf config file and so did the unit file of the original F16 vsftp rpm - albeit totally broken.  But the new vsftpd-2.3.4-6.fc16 unit files assumes there only is a single instance which is a step backward.  Otoh multiple copies of the unit files is not a good solution because it makes upgrades harder should the unit file change and I think all instances of vsftpd should rather be considered a single service than multiple.

A /lib/systemd/system/vsftpd@.service unit file like the following:

[Unit]
Description=Vsftpd ftp daemon
After=syslog.target network.target

[Service]
# Follow the steps below to set up an additional configuration file:
#
# cp /etc/vsftpd/vsftpd.conf /etc/vsftpd/vsftpd2.conf
# ln -s /lib/systemd/system/vsftpd@.service /etc/systemd/system/multi-user.target.wants/vsftpd
#
Type=oneshot
ExecStart=/usr/sbin/vsftpd /etc/vsftpd/%i.conf
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
Alias=multi-user.target.wants/vsftpd

works fine for me.  This file really is just a minor modification from the original F16 rpm's unit file.

(In reply to comment #12)
> Re. FTP not working with user accounts in comment #9, this is another known bug
> - see https://bugzilla.redhat.com/show_bug.cgi?id=752827 for more info.
> 
> Assuming your default shell is bash, then the quickest fix is to add the line
> "/bin/bash" to the end of "/etc/shells" if it's not already present, or if you
> don't feel happy editing config files by hand run the following command:
> 
> sudo echo /bin/bash >> /etc/shells
> 
> A pending update to the bash package should fix this for good.

As of 2012/01/10 09:08, this is still missing.  

 I added /bin/bash, which seems to now allow anonymous login, but normal user login is still denied:
 
 500 OOPS: cannot change directory: /home/rjflory
 Login Failed.

 This even happens with user dir perms set to 0777.

(In reply to comment #18)
> (In reply to comment #12)
> > Re. FTP not working with user accounts in comment #9, this is another known bug
> > - see https://bugzilla.redhat.com/show_bug.cgi?id=752827 for more info.
> > 
> > Assuming your default shell is bash, then the quickest fix is to add the line
> > "/bin/bash" to the end of "/etc/shells" if it's not already present, or if you
> > don't feel happy editing config files by hand run the following command:
> > 
> > sudo echo /bin/bash >> /etc/shells
> > 
> > A pending update to the bash package should fix this for good.
> 
> As of 2012/01/10 09:08, this is still missing.  
> 
>  I added /bin/bash, which seems to now allow anonymous login, but normal user
> login is still denied:
> 
>  500 OOPS: cannot change directory: /home/rjflory
>  Login Failed.
> 
>  This even happens with user dir perms set to 0777.

As with so many other things, disabling SELinux 'fixed' this...

> > 
> >  I added /bin/bash, which seems to now allow anonymous login, but normal user
> > login is still denied:
> > 
> >  500 OOPS: cannot change directory: /home/rjflory
> >  Login Failed.
> > 
> >  This even happens with user dir perms set to 0777.
> 
> As with so many other things, disabling SELinux 'fixed' this...

You have to set following selinux boolean:

# setsebool ftp_home_dir on

hi all, i have the same problem, i can't login with anything user please help me!
i set selinux ftp_home_dir on. I can login with anonymous user but i can't login with other user, i did all things that you say here!