SFTP is not FTP

Today I encountered another confused person who thought that to provide SFTP service, he had to install an FTP server.

I'm writing this post so that I can point people to it next time I encounter this misconception.

Yes, SFTP stands for Secure File Transfer Program and FTP stands for File Transfer Protocol but there the similarity ends. SFTP is run over a ssh connection, which normally uses the single service port 22. FTP is a different protocol using two ports, normally 20 and 21 for data and command (I will not go into the complexity of active and passive modes here). They are not related. The Wikipedia entry for FTP explains it succinctly. SFTP servers are different from FTP servers. Although there are clients that are capable of connecting to both types of servers, for example, Filezilla.

If you can ssh to a server, you can probably sftp also. I qualified that claim with "probably" because the sftp functionality has to be enabled and allowed to users.

SFTP is much much preferred over FTP due to encryption of the stream.

To complicate things there is a variant of FTP called FTPS which uses TLS to encrypt the stream.

What good is the --target option of cp?

If you look at the man page for cp(1) on operating systems where the GNU tools are used, such as Linux, you will see there is an third form that uses the -t option or alternatively the equivalent long form --target.

cp [OPTION]... -t DIRECTORY SOURCE...

So what good is this when you already can do:

cp [OPTION] SOURCE... DIRECTORY

Here's a reason. Suppose the SOURCE list is large and comes from a file or another command. So you have to use the xargs command to invoke cp as many times as necessary to consume the list, without running into command line argument limits. Assuming the source list is one per line, you could do something like this:

xargs -d '\n' cp -pr -t destdir < listofsources

The -t allows the destination directory to be put before the source arguments in the cp command. Without it,  you would have to resort to the interpolation feature of xargs, i.e. -I {}

TXT_DB error number 2 when generating openvpn client certificates

You may have followed the openvpn quick start instructions either from the online tutorial or using the README file in easy-rsa where it asks you to go through these steps:

[edit vars with your site-specific info]
source ./vars
./clean-all
./build-dh
./pkitool --initca
./pkitool --server myserver
./pkitool client1

 and then you get

failed to update database TXT_DB error number 2

at the last step. I did and a web search mostly turned up suggestions to run ./clean-all again. But this article was the key. It's about openssl, but openvpn's easy-rsa is just a front-end to openssl. The important observation is that every certificate must have a unique CN in the database. In the file vars, this is controlled by KEY_CN. You left the settings read in from vars unchanged between generating the server cert and the client cert. You could edit vars before generating the client certificate and re-source vars, or you could do this before generating each client key.

KEY_CN=someuniqueclientcn ./pkitool client1

and you will stop getting that TXT_DB error.


I'm a bit surprised that the documentation for openvpn hasn't been updated to make this clear.


NB: It is also affected by the setting unique_subject = yes in the file keys/index.txt.attr, but I prefer not to go against the default setting.

How to get a list of installed software on RPM based systems

You might want to do this to know what packages to restore, or to discover the difference between two installations.


In this article, the suggested command is rpm -qa. That is correct, but it has a problem. It will list the package names without the architecture. If you are on an x86_64 system, there may be both x86_64 and i386 packages. If you use the generated list to (re-)install the software you may end up getting both architectures. You would get extra packages or worse, there may be a conflict due to common pathnames in the two architectures.


Therefore we need to also output the architecture with the package name. For this we use the --queryformat option of rpm, or the shorter form --qf.


rpm -qa --qf '%{NAME}.%{ARCH}\n' > listofpackages

Don't install VirtualBox on Windows from a network share

Why not, you ask? Well during the installation process, network device drivers are installed (the cause for the several popup warnings about unverified software). These break the network connection temporarily and of course if your installer package is on a network share, your installation stops dead. Duh, stupid me. So install it from a local disk. A USB stick is also ok.


There is actually a longer story in my case. I was upgrading versions. After I realised my mistake I installed from a local drive. But unknown to me damage had already been done. It worked fine for a while. Then one day I decided to do some disk cleaning. Hmm, how come I have both 4.1.14 and 4.1.16 installed? Never mind, I'll blow away 4.1.14. Everything appeared to be still ok afterwards.


Next I needed to enable bridged networking for the Learning Puppet VM. No matter what I did, I could not obtain an interface to bridge. A search turned up this troubleshooting advice in the VirtualBox manual. To paraphrase, one reason for no bridged network adapter is MaxNumFilters is too low. Well, that wasn't it. It was another reason: "The INF cache is corrupt". After I removed %windir%/inf/INFCACHE.1, rebooted and reinstalled VirtualBox, bridged networking became available. It must have been using the driver from the previous release of VirtualBox because I had a partial install of the current version.


So that advice again: Install the VirtualBox package on Windows from a local disk.

Expanding an ext3 partition

As has been documented at howtoforge, here and many other places you can find with a search, resize2fs can expand your ext3 filesystem without losing data. (It's actually one case of resizing, you can also shrink.) You have to extend the containing partition first, using parted or the CLI way, by deleting and recreating the partition with a higher cylinder boundary.


I just want to add a few comments. 1. The switching to ext2 and back mentioned in the howtoforge article isn't necessary any more. 2. You can do this on a partition that is not needed for system operation like /home without booting to a rescue disk. This is useful if you have only online access to the server. In fact I did the expansion in parallel with some (tested) RHEL package updates. 3. It works exactly as expected for SAN volumes. It was very nice with a SAN, all the SAN manager had to do when I requested an expansion was to issue a command for the SAN to increase the "disk" size and it finished the task in a few hours.


If you are using logical volume manager, then you have other options too.

Samba, SELinux and the homes share

As has been documented here and many other places, on Redhat, CentOS, Fedora and other distros that come with SELinux enabled, you have to enable the SELinux boolean samba_enable_home_dirs if you export the homes share. I did this but I still could not connect to the share. The usual error message is NT_STATUS_BAD_NETWORK_NAME.


It turns out that you need samba_export_all_ro or more likely, samba_export_all_rw enabled to mount the share. This was on CentOS 5.5. It could be that on this distro and version both come disabled by default.


Make sure though that SELinux is the cause. There are many other reasons for NT_STATUS_BAD_NETWORK_NAME. A quick way to check is to set SELinux to permissive temporarily to attempt the connection.