Present Perfect

Recently we got a new server for apestaart, our little hosting project between friends.

This time we decided to install CentOS, since people I trust have been saying good things about it, we use RHEL at work and it's pretty much the same, and Wiebe, the other admin, also was all for it.

This week I ran into a segfault and I wanted to debug it. Turns out CentOS ships without any debug repositories installed by default. Fedora installs the files, but cleverly disables them, as they should. But yumutils contains debuginfo-install, a handy script that allows you to install all the dependencies of a -debuginfo package, and gdb spits out useful commands like what packages to install when you're looking at a stack trace with missing symbols.

So, this doesn't work out of the box on CentOS. Fail #1.
I went on IRC, mentioned this there, and I was told that 'most CentOS users don't need debuginfo packages'. Fail #2 - neither do Fedora users, yet somehow Fedora managed to figure out how to work both for the ones that don't need them and the ones that do. So goodbye unhelpful IRC channel.
I had to manually create a .repo file based on some guy's post complaining about the same thing; something much like this:
[root@betsy ~]# cat /etc/yum.repos.d/debuggery.repo
[debuggery]
name=CentOS-$releasever - DebugInfo
baseurl=http://debuginfo.centos.org/$releasever/$basearch/
priority=1


Then I actually tried to do debuginfo-install python, and what happened ?

First of all, the python-debuginfo package for the installed version of python isn't even in that repo (though 3 others are, go figure). FAIL #3

Of the other packages that it did find, one was unsigned:

yum.Errors.YumBaseError: Package libtermcap-debuginfo-2.0.8-46.1.x86_64.rpm is not signed


FAIL #4.

CentOS, hostile to developers. Back to old-school 90's style rpm hunting and pecking on the web.

UPDATE:
As for the python debuginfo package, there is a RHEL5 package with exactly the right version and release tag, but that one was built for RHEL5, and installing it mismatches against the CRC of the installed python package. CentOS simply does not provide the debuginfo package for its shipped version of python. FAIL #5

Recently we got a new server for apestaart, our little hosting project between friends. This time we decided to install CentOS, since people I trust have been saying good things...

Today I'm doing some cleanup and maintenance work, and going through some pending GStreamer account requests.

I'm not a GPG expert, and I'm sure all of you are, so help me figure this out.

If someone creates a bug report and attaches their public GPG key, why should I trust that it is correct ? What should I do to verify it ?

AFAICT, anyone can file a bugzilla ticket, claim to be some other person B, and ask to change GPG and SSH keys for that person B.

What am I missing ?

Today I'm doing some cleanup and maintenance work, and going through some pending GStreamer account requests. I'm not a GPG expert, and I'm sure all of you are, so help...

I had a long discussion today with Arek about file permissions and security. We ended up trying to figure out how the default install of Apache works on Fedora and Debian, and if that is the most secure solution.

So, here's my understanding of the default config on these two distros in a nutshell:

• apache starts as root and then drops to a specific user(httpd on Fedora or www-data on Debian)
• config files are owned root:root with 0644 permissions
• the default config is secure (doesn't contain important secrets
• because of this, it's not a big deal that any user that can log in to the system can read the config files

So, imagine you want to protect part of your site. You add a configuration parameter to specify which htpasswd file to use, and you make this htpasswd file be owned by root:apache and with 0640 permissions. This way, no one else than root and the apache group can read this file. So far, so good - logged on users cannot read the file and run a cracker on it to guess plaintext passwords of all your users.

So, imagine you now want to add LDAP authentication, and you need to put the plaintext password for your LDAP proxy user. The config hints that you should do something special to protect this:

A bind password to use in conjunction with the bind DN. Note that the bind password is probably sensitive data, and should be properly protected

.

I read this as "make sure that your normal users on your machine can't read the file that contains this information". So apache should be able to read it, and (possibly but not necessarily) root, but no one else. So, a logical way for me is to put an include statement in the apache config for a file that is root:apache and 0640, which contains the bind password.

Which got me to thinking - Why is the default apache config not root:apache and 0640 to begin with ?

Arek's reasoning was that it's fine for the default config to be more open, and you should know what you are doing (which implies, changing ownership and permissions if you put this password in the main config file). My argument is that it would be more helpful to have the default setup be locked down more, so that putting this plaintext password in that config - a reasonable thing to do when you want to do some more advanced config - does not suddenly make your setup a lot less secure.

So, I'm sure there is a reason why apache (and other daemons) have their config as root:root and 0644 instead of root:$(daemonuser) and 0640. Anyone care to share their opinion on the subject ?

I had a long discussion today with Arek about file permissions and security. We ended up trying to figure out how the default install of Apache works on Fedora and...

By now we have three platforms we're managing - one internally for development, and two external ones. It gets a little tedious always typing the right commands to log in to them, and it gets a little dangerous because the hostnames are named relatively consistently across the platforms, and a terminal prompt only shows the first part. So, "myimportantserver" would exist in all three platforms, and it's just no fun at all to discover that you typed "reboot" in the wrong window.

Here's how I set up a gnome-terminal launch icon on my desktop for each platform:

• Create a new profile in gnome-terminal (Edit>Profiles, New)
• Give it the name of your platform/group of hosts, for example my.platform
• Edit the profile, go to the "Title and Command" tab, and select "Run a custom command instead of my shell"
• As the custom command,enter "ssh firsthost.my.platform"
• In the Colors tab, deactivate "Use colors from system theme"
• Pick a background color that will remind you of this platform
• Right-click on a panel, add a custom launcher
• Give it a name like "Terminal my.platform"
• As the command, use "gnome-terminal --window-with-profile=my.platform"
• Pick an icon (Would it not be nice to have nautilus's emblems for this ?)

Now, clicking the icon should give you:

• a terminal window
• with a login on that machine
• in a different color than your normal terminals, so you really know what platform you are on

Make sure you make log-ins very easy by using ssh keys, and using a desktop running under ssh-agent, so you can ssh-add your key once and then log in to these machines with a single click.  You should make it easy to jump from this entry point host to the other hosts on your platform, by using authentication forwarding for this first host.  This makes going to the next one as easy as typing "ssh nexthost"

Now, for the dessert: open a new tab in this terminal and see what happens!

By now we have three platforms we're managing - one internally for development, and two external ones. It gets a little tedious always typing the right commands to log in...