X11 connection rejected because of wrong authentication – X11 forwarding suddenly fails

After ages of flawless X11 forwarding over SSH, today I started getting authentication errors and couldn’t even get a remote xterm to display locally over my ssh tunnel.

Weird!

I tried ssh -Y, ssh -X and changes in sshd_conf on the remote server and ssh_conf locally, even though I knew that nothing had changed except a few patches to unrelated software on the local machine. Of course that didn’t help.

I ran xauth on the remote server, no indication of any errors.

It turned out that the remote /home filesystem was out of space, and this prevented the ssh X11 forwarding from working properly. I write this as a note-to-self, as it could happen again…

gentoo gnunet build fails with MHD_post_process linker error

gnunet ebuild (zugaina layman overlay) fails with linker errors about MHD_destroy_post_processor and MHD_post_process ?

Add to /etc/portage/package.use:

net-libs/libmicrohttpd  messages

emerge libmicrohttpd again, and then emerge gnunet.

Success!

(at least for me)

RHEL6 apache httpd virtual host the proper way

My recipie for name based virtual hosts in separate directories on RHEL:

We place all the virtual hosts under a new directory tree /var/www/vhosts:

# yum install httpd
# mkdir /var/www/vhosts
# semanage fcontext -a -t httpd_sys_content_t /var/www/vhosts
# restorecon -Rv /var/www/vhosts
# mkdir -p /var/www/vhosts/{site1,site2,site3}/{logs,htdocs}
# chown -R apache:apache /var/www/vhosts

I recommend using the FQDN of each site instead of the words “site1”, “site2”, in these examples.

Create the file /etc/httpd/conf.d/vhosts.conf with appropriate content such as:

NameVirtualHost *:80

<VirtualHost *:80>
  ServerName site1
  DocumentRoot /var/www/vhosts/site1/htdocs
  CustomLog "/var/www/vhosts/site1/logs/access.log" common
  ErrorLog "/var/www/vhosts/site1/logs/error.log"

  <Directory "/var/www/vhosts/site1/htdocs">
     Options None
     AllowOverride All
     Order Deny,Allow
     Allow from 127.0.0.1
  </Directory>
</VirtualHost>

<VirtualHost *:80>
  ServerName site2
  DocumentRoot /var/www/vhosts/site2/htdocs
  CustomLog "/var/www/vhosts/site2/logs/access.log" common
  ErrorLog "/var/www/vhosts/site2/logs/error.log"

  <Directory "/var/www/vhosts/site2/htdocs">
     Options None
     AllowOverride All
     Order Deny,Allow
     Allow from 127.0.0.1
  </Directory>
</VirtualHost>

and so on

(Dont forget to set the Directory permissions properly. Above is just an example!)

Then activate the goodness:

# apachectl restart

Why is this method good?

1. Creating the vhosts.conf in conf.d doesn’t modify any vendor-supplied files, which means that we won’t lose them if we reinstall the package.

2. Keeping each virtual host and its logs under its own directory tree makes maintenance a breeze and permissions can be separated to give developers access to specific vhosts only.

Error: Cannot retrieve repository metadata (repomd.xml) for repository: epel. Please verify its path and try again

Error: Cannot retrieve repository metadata (repomd.xml) for repository: epel. Please verify its path and try again

I tried installing EPEL on a fresh install of RHEL6, and after adding the repo, yum fails with the above error. I have RHEL6.1 (Santiago) and get the above error.

This happens because the RHEL/CentOS installation doesn’t trust the HTTPS certificate used by mirrors.fedoraproject.org, that is issued by “GeoTrust SSL CA“.

In my case the package ca-certificates was not installed and the /etc/pki/tls/certs/ folder didn’t contain any ca-bundle.crt or ca-bundle.trust.crt !

Solution: yum install ca-certificates

(I had to temporarily rpm –erase epel-release first, to get yum working again)

I once got the same error message eventhout ca-certificates was installed and up to date. Then it was a firewall blocking https (port 443) traffic.

I worked around that by changing from https to http in /etc/yum.repos.d/epel.repo

RHEL6 package name for libdb is db4

Close to impossible to understand, but I just spent quite some time to figure out the package name for the Berkeley DB, libdb on RedHat (RHEL6).

Silly me. I should have known that the package is called “db4” and nothing else. After figuring that out, tacking on a “-devel” to get the headers package was piece of cake.

Howto install perl modules

I often find myself trying to install (binary) packages that have dependencies to perl modules.

Because I work on varying platforms, sometimes RHEL/RedHat, CentOS, sometimes Debian based, like Ubuntu, and sometimes, less often now, but maybe I will go back again, to Gentoo. In many ways my ideal platform.

However, Perl is wicked, and the concept of perl modules in a package manager is even more crazy.

What are we going to do when we need a new version of a software (say, amavisd-new) that is not available in the distros package library?

I’m thinking, build from source and you can’t go wrong, right?

In the case of amavisd-new, these are the listed prerequisites:

Archive::Zip   (Archive-Zip-x.xx) (1.14 or later, currently 1.23)
Compress::Zlib (Compress-Zlib-x.xx) (1.35 or later, currently 2.008)
Compress::Raw::Zlib (Compress-Raw-Zlib) (2.017 or later)
Convert::TNEF  (Convert-TNEF-x.xx)
Convert::UUlib (Convert-UUlib-x.xxx) (1.08 or later, stick to new versions!)
MIME::Base64   (MIME-Base64-x.xx)
MIME::Parser   (MIME-Tools-x.xxxx) (latest version from CPAN - currently 5.425)
Mail::Internet (MailTools-1.58 or later have workarounds for Perl 5.8.0 bugs)
Net::Server    (Net-Server-x.xx) (version 0.88 finally does setuid right)
Digest::MD5    (Digest-MD5-x.xx) (2.22 or later)
IO::Stringy    (IO-stringy-x.xxx)
Time::HiRes    (Time-HiRes-x.xx) (use 1.49 or later, older can cause problems)
Unix::Syslog   (Unix-Syslog-x.xxx)
BerkeleyDB     with bdb library (preferably 4.4.20 or later)
Mail::DKIM     (Mail-DKIM-0.31 or later)

So, if I’m going to install amavisd-new, from souce, on a RHEL6 server, what do I need to do? -Well, I’ll show what I did. Not neccessarily what is the best thing to do… OK?

yum install cpan
perl -MCPAN -e shell

(going with the defaults, automatic is nice)

When I attempted to install the first module (Archive::Zip), I discovered that I did not have web access from my server, so I had to download the CPAN modules by hand. I did this by using the powerful http://search.cpan.org/ search tool, and just pasting the package name (Archive::Zip) in the search box and then downloading the tar.gz packages one at a time.

Manual installation of 1 CPAN package:

tar zxf Archive-Zip-1.31_04.tar.gz
cd Archive-Zip-1.31_04
perl Makefile.PL
make
make test
sudo make install

Had I had internet connection available:

perl -MCPAN -e 'install Archive::Zip'

The beauty of CPAN installation is that it resolves dependencies automatically.

authorized_keys SELinux pubkey authentication on RHEL / CentOS

So, you have correct permissions on your home directory and all the way up to /, with no other-writable directories in the path, as well as correct permissions on the .ssh directory in $HOME, and it still doesn’t work? You probably have SELinux, and need to put the newly created files in the correct security context. Do it with restorecon like this:

chmod 700 ~/.ssh
cd ~/.ssh
chmod 600 ~/.ssh/*
chmod 644 ~/.ssh/authorized_keys
chmod 644 ~/.ssh/known_hosts
chmod 644 ~/.ssh/config
restorecon -R -v ~/.ssh

 

uuencode package name

Sometimes you have a tiny file you wish to include in a block of plain text, perhaps an email. When I was young(er), -in the era of UUCP and modems, before the world wide web and HTML were invented, when RFC-821 was still new, -there were no MIME attachments to email.

If you wanted to send a file by mail, you had to encode it in a way that could be included in plain text without breaking. That meant 7-bit ASCII only, max 72 chars on each line, and a lot of other limitations.

Bandwidth and storage were limited, so uuencode was invented to “efficiently” encode 3 bytes of binary data into 4 printable characters. Pretty clever.

I recently had a need for uuencode, and it was not installed on my CentOS/RedHat system by default. The package containing uuencode is called “sharutils”. The name comes from the “shar” utility to encode binaries into a shell script, shell archive (shar file).

yum install sharutils” – and voila, I have uuencode and uudecode available.

(Re)discover new LUN in linux without rebooting

Note to self… Has 1 disk (/dev/sda) and want to “find” newly added disk (/dev/sdb) without reboot:

echo 'scsi add-single-device 0 0 1 0' > /proc/scsi/scsi

The first “0” is the controller, next “0” is the SCSI channel, the “1” is the target ID, and the last “0” the H-LUN.

After repartitioning with fdisk, the kernel remembers the old partition table, so remove the device and add it again to refresh it:

echo 'scsi remove-single-device 0 0 1 0' > /proc/scsi/scsi
echo 'scsi add-single-device 0 0 1 0' > /proc/scsi/scsi