After a successful adventure with vsftpd in MX, Debian, and Devuan, I decided to try it in Gentoo.
Followed the instructions from https://wiki.gentoo.org/wiki/Vsftpd
and it installs OK, and I can start the daemon with OpenRC
but
The configure instructions are only for anonymous ftp and I did not want that, I wanted user login and password access only. The install did not make a file /etc/vsftpd.conf
So I looked elsewhere for how to configure the file /etc/vsftpd.conf and found https://wiki.gentoo.org/wiki/Vsftpd/AD_Authentication
which has an example vsftpd.conf as follows
[nevj@trinity ~]$ ftp 192.168.0.46
Connected to 192.168.0.46.
220 Welcome to FTP-server.
Name (192.168.0.46:nevj):
331 Please specify the password.
Password:
500 OOPS: vsftpd: refusing to run with writable root inside chroot()
ftp: Login failed.
421 Service not available, remote server has closed connection
I dont understand the message about chroot()
I tried several other examples including
my vsftpd.conf from Debian
Gentoo VSFTPD Howto
none of those worked,
so I went back to the above listed example and commented out the line
chroot_local_user=YES
and then it works
[nevj@trinity ~]$ ftp 192.168.0.46
Connected to 192.168.0.46.
220 Welcome to FTP-server.
Name (192.168.0.46:nevj):
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
....
ftp> mget sync.ou*
mget sync.out? y
200 PORT command successful. Consider using PASV.
150 Opening BINARY mode data connection for sync.out (923 bytes).
226 Transfer complete.
923 bytes received in 0.000294 seconds (2.99 Mbytes/s)
ftp> bye
221 Goodbye.
So by a bit of guesswork I got it to function, but I still do not understand what the official example from Gentoo complained about writeable root inside chroot()
or why I has to comment out the chroot_local_user=YES line.
The Debian config file has this line commented out, but it did not work for some other reason.
I would really like to know what is the minimal working configuration for vsftpd that would work in any distro. All the examples I tried have added features that just make it non-portable and unnecessarily complicated.
That will allow username/password logins but not anonymous logins , and will allow you to write on the host filesystem ( eg do an upload).
Thank you @abhishek for cutting through all the unnecessary sophistication.
Now I understand what I am doing.
There is another more extensive ftp article here
It deals with active and passive ftp and how to handle firewalls.
I now have vsftpd running in all my Linux installations, except Void. In Void there is still available the original ftpd daemon. It comes packaged with the original ftp in a package called inetutils-ftp. It requires no configuration file at all. I guess that is the ultimate minimum config. I will continue to use original ftpd in Void.
I have a love / hate relationship with USE and keywords in Gentoo. Hate when I spend hours negotiating with Portage over use changes and solving one issue only to be informed that the solution created two, or sometimes more problems – and Love when I realize that I haven’t experienced upgrade anxiety in years, which had been a constant over the preceding couple of decades using Linux. The two things that contribute the most to Portage being a righteous pain in the ass, are also the thing that - if you jump through all the hoops - result in a system that is virtually unbreakable.
I have not experienced keywords yet. My limited experience with use flags suggests that it is all about compiling apps with options… either optional library links or other compiler options. One really needs to understand the app and how one wants to use it, to set the use flags appropriately.
At the moment, while still learning, I am being conservative and only setting flags th
at are absolutely necessary.
Portage is a big learning curve
I can remember having to “deal” with PASV 25+ years ago when traversing firewalls to grab “warez” (e.g. “0 day warez”)…
Sometimes I’d be doing it from a NIX shell, with the ncftp client (which was rather neat actually) - or ws-ftp client (which I’d usually download from TUCOWS ) on Windows 3.11 or 95, but it still allowed you to type commands, so you could type “PASV”… From memory the MS-DOS version of FTP (that I think got installed with the “TCP/IP Addon for Windows for Workgroups”) wasn’t very good at things like PASV…
I haven’t tried to grab “warez” for over 20 years at least. Everything software I need is OSS, and games on Steam are reasonably priced…
This is what makes Gentoo. There are only about three keywords, that I really use, when building a 32bit system you set ACCEPT_KEYWORDS=“x86” you would then set amd64 or ~amd64 in /etc/portage/package.accept_keywords/package.accept_keywords
If you are building a 64bit system you can use either amd64 or ~amd64, my hardware works best with the amd64, the ~amd64 is for a more-like Arch build.
The Gentoo wiki says the ~ prefix is for testing rather than stable… so yes more Arch-like
Keywords seem to be about architectures. The wiki seems to say it is possible to use a package from another architecture.
I guess one might try that if that was the only place it was available. … but I would be more inclined to get the source code in that situation… like we did recently with aa.
Actually, there’s no reason to put that line in make.conf when you’re on an x86_64 computer. The amd64 keyword denotes the stable branch of the repo which, unless otherwise specified, would be the keyword and branch to which Portage would default.
The keyword “~amd64” placed in make.conf would, on the other hand, instruct Portage to build any package, system wide, from testing source wherever possible.
That may be true, but I find it better, to keep portage to amd64 instead of relying on the default. I sometimes use ~amd64, on a few packages. I’m sure you have more experience with Gentoo than I, and appreciate your input.
Applying the ~amd64 keyword global by doing so in make.conf would result in an Arch-like system in that the packages would be fresh, yet close enough to being moved to stable that they are not very risky to use. It’s most definitely not Arch-like in that the install would be anything but minimal. Portage interprets “~amd64” applied globally to mean build everything in testing that’s available for x86_64 and compatible with your system and the resulting list of packages to be built is massive. If, for instance, you were initially installing Gentoo using the desktop profile, the first emerge after installing the stage 3 tarball would only require about 20 or so packages to get the base system up and running. With “~amd64” added to make.conf, that initial emerge jumps to somewhere in the neighborhood of 300 packages.
As far as the Gentoo Handbook on keywords goes, it’s one of the least effectively written sections in the otherwise clear and helpful guide. It’s easy to infer from the way it’s (poorly) explained that “packages” from different architectures can be mixed. That’s not the case and the reason is essentially and exercise in semantics, but, because the concept is basic to understanding how Gentoo works, a fairly important one. Except for rare exceptions, none of which take place in the initial install, there are no packages for Gentoo to install. The packages are build from source code that, in almost all cases, is the same regardless of architecture. The machine on which the source code is compiled determines what architecture the resulting package will be for.
What the keywording instructions in the handbook that talk about other architectures are instructing Portage to do is:
–if the source code for the package has compiled successfully and is stable on another architecture (or on any other architecture) then unmask and install it even if not considered stable for my architecture.
The best practice when using keywords to point portage at alternate branches of the repo( “-amd64” for testing, or “missing keyword” for unstable/experimental) is, exactly as you do, applying them at the package level. If you put “~and64” in make.conf and then run emerge -avuND @ world, the build Portage would propose would be massive - possibly hundreds of packages…
On an x86_64 system, there are very rare situations where amd64 may be needed as a USE flag and I put it in USE in make.conf so that all of those possible situations will be covered without portage kvetching about them. As a keyword, however, amd64 is completely ignored by portage.
So could I use keywords to build a package for another architecture, different from the machine in which I compile? In other words will it cross-compile a package?
I can think of cases where source code has to be changed, eg in moving from 32 bit to 64 bit, integer sizes in C may have to be changed.
Oh, I have, a few times, when building to a VM, it
can get out of hand very quickly. I sometimes use a
kernel that is masked by the ~amd64, so I use the
~amd64 to unmask the package.
Do you by any chance build your own kernel, through the
make menuconfig? I am mostly using a Distribution Kernel for a
lot of my builds “gentoo-kernel-bin”, seems to work out, for how
I use Gentoo. I have played with the manual build, and even got
the machine to boot, but that manual kernel build is really time
consuming. I do wis there were more documentation on the process
of a manual build.
(e.g. “0 day warez”)…