Get the SSH fingerprint of an SSH server

If you've ever tried to connected to a new server over SSH, you would've seen a message similar to the following:

# ssh iridium The authenticity of host '[foo]' can't be established. RSA key fingerprint is a2:b9:c5:d3:e5:fc:a6:b3:c7:da:e1:f0:ac:b9:c9:d5. Are you sure you want to continue connecting (yes/no)?

Then you may have wondered, "Well, what *is* the fingerprint of my server supposed to be?". Basically, in order to do the authentication of the host, you should run the command below (at SSH server install time, or over a "secure" channel) in order to get your hosts SSH fingerprint:

# ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub 2048 a2:b9:c5:d3:e5:fc:a6:b3:c7:da:e1:f0:ac:b9:c9:d5 root@foo (RSA)

You should then be able to compare the two fingerprints to determine whether the server you're connecting to is in fact the one you're trying to connect to and isn't some sort of honeypot.

Command to delete a particular host from known_hosts

Occasionally (especially in the cloud world, where instances are cattle), the SSH fingerprint for a host changes. When this happens, you will see a warning.
If the warning is expected, the usual remedy is to delete the offending key from your "known_hosts" file (typically found under ~/.ssh/known_hosts). However, when you need to do this across a bunch of machines and you don't know what line number the host will be on, on each machine, the following command might be useful:

sed -i -e '/\[webserver-03.example.com\]:2222/d' ~/.ssh/known_hosts

It deletes any line which matches the host "[webserver-03.example.com]:2222" in the default "known_hosts" file.

Online courses

I've signed up to Code School to try it out. So far, have done three different courses:

* Try Ruby
* Javscript Roadtrip 1
* Try Git

All three seem really basic, geared towards people that don't know how to program. Site doesn't appear to have very many free courses and costs $29USD per month to get full access.

Apparently the two other sites which offer courses of a similar nature are Treehouse and Codecademy.

I've also had recommended the Crypto 101 course and will probably be trying that one out next.

Whatever course site (MOOC?) I sign up for, it would be really great if they integrated Open Badges.

Getting Firefox Sync server running

Have been setting up Firefox Sync, following the instructions found at: https://docs.services.mozilla.com/howtos/run-sync-1.5.html

The instructions were pretty straight-forward, got it up and running in no time (even ran the tests to ensure everything was passing).

However, after reconfiguring the browser to point to the new Sync URL, nothing happened. (In the end it turned out I forgot the "/token/" part of the URL: https://bugzilla.mozilla.org/show_bug.cgi?id=1032039)

Debugging Tips:

* By default if you run the server using "local/bin/pserve syncserver.ini" the server logs to console.

* The database the server saves to (by default) is "syncserver/syncserver.db", which you can view using SQLite Browser.

* To manually start a Sync, you can go to "Tools" -> "Sync Now"

* To view the browser (client) sync logs, enter "about:sync-log" in the URL bar. You can turn on logging on successful sync by toggling the "services.sync.log.appender.file.logOnSuccess" configuration variable.

* At time of writing there's a bug where the URL can be set back to the default in some instances: https://bugzilla.mozilla.org/show_bug.cgi?id=1003708

* You can modify the "services.sync.syncInterval" variable to make the browser attempt to sync more frequently (value is in milliseconds).

Getting Risk of Rain working

I bought the Humble Indie Bundle 13 and downloaded Risk of Rain (non-Steam version). Tried firing it up, when it wouldn't run, giving error:

"error while loading shared libraries: libopenal.so.1"

Found that it required a bunch of 32-bit packages, namely:

* libopenal1:i386
* libxrandr2:i386
* libglu1-mesa:i386

 which you had to install with "sudo apt-get install [package name]"

NOTE: To get "Shadowrun Returns" working, also had to install the "libxcursor1:i386" package.

NOTE2: Am running Ubuntu 14.04LTS 64-bit

Firewall configuration in CentOS 7

CentOS 7 introduced firewalld to replace iptables. As a result, the "system-config-firewall-tui" command no longer works (unless you re-install iptables).

The equivalent way of adding in a couple of ports to the firewall rules is as follows:

sudo firewall-cmd --add-port=4505/tcp
sudo firewall-cmd --add-port=4506/tcp

The above will add rules to open the ports, but the change won't survive a reboot. To make the changes permanent, just add the "--permanent" flag to the command.

Configuring PostgreSQL to listen on all IPs

Tested on CentOS 6. Modify the line:

listen_addresses = '*'

In the /var/lib/pgsql/data/postgresql.conf file.

Setting root password on CentOS MySQL install

After installing and starting up mysqld run the following commands to set the root password:

# /usr/bin/mysqladmin -u root password '[password here]'
# /usr/bin/mysqladmin -u root -h [hostname here] password '[password here]'

Common SELinux problems and tasks

List current selinux context labels on files:

[root@machine1:/var/www/html]# ls -alZ
total 124K
drwxr-xr-x. root   root   system_u:object_r:httpd_sys_content_t:s0 ./
drwxr-xr-x. root   root   system_u:object_r:httpd_sys_content_t:s0 ../
drwxr-xr-x. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 administrator/
drwxr-xr-x. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 bin/
drwxr-xr-x. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 cache/
drwxr-xr-x. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 cli/
...


Change the selinux context:

[root@machine1:/var/www/html]# chcon -Rv --type=httpd_sys_content_t ./*
changing security context of `./administrator/templates/hathor/less/forms.less'
changing security context of `./administrator/templates/hathor/less/buttons.less'
...


Enable Apache to make outbound database connections:

[root@machine1:/var/www/html]# setsebool -P httpd_can_network_connect=1

Enable Apache to use sendmail:

[root@machine1:/var/www/html]# setsebool httpd_can_sendmail 1

Finding the CWD (current working directory) of a running process

Luckily, due to the UNIX philosophy of "everything" is a file, makes it rather trivial to find what the current working directory is. You just need to look at the symbolic "cwd" link under the process directory:

# ls -al /proc/[process number here]/cwd lrwxrwxrwx 1 build build 0 Oct 18 12:29 /proc/2506/cwd /root/run

Gerrit and ActiveDirectory

We've recently started testing out Gerrit at work and one of the tasks when setting it up was to integrate the authentication with ActiveDirectory.

The process was fairly straight forward. For reference here is an example AD configuration:

[ldap]
 server = ldap://dc.company.org:389

 accountBase = ou=People,dc=company,dc=org
 accountPattern = (&(objectCategory=Person)(sAMAccountName=${username}))
 accountFullName = displayName
 accountEmailAddress = mail

 groupBase = ou=Groups,ou=People,dc=company,dc=org
 groupMemberPattern = (&(objectClass=group)(member=${dn}))

 username = cn=Gerrit User,ou=People,dc=company,dc=org
 password = ********

The username/password are for the "bind" user that will be used to query the server. More information can be found on the Gerrit auth documentation page.

Simple Perl and CGI example

This is probably the simplest possible example to get Perl working through cgi on Apache HTTPD. Instructions are for Ubuntu 12.04.

Install apache httpd:

sudo apt-get install apache2

Add the following "hello.pl" script to the /usr/lib/cgi-bin directory:

#!/usr/bin/perl

print "Content-type: text/html\n\n";
print "Hello World!";
exit;

Point your browser at http://localhost/cgi-bin/hello.pl and that's it!

etckeeper and bzr explorer

In my previous blog post, I talked about using the etckeeper package for keeping the entire /etc directory under version control. In this post I'll talk about how to manually audit the changes to see what changes were made and also how to reverse those changes, using the "bzr explorer" program.

To do this, we need to install the "bzr-explorer" package. Once this is done, you have to start up the GUI as the root user:

sudo bzr explorer

NOTE: I initially tried starting it up as a non-root user and it was not able to load the repository.

Once we've got this open, we can go to the "Open an existing location" pane and select the "Open" button. Navigate to the "/etc" directory and click on "Choose". This will load up the repository in the explorer window.

Now, if someone has modified a file under /etc but hasn't committed it, the screen will look like the following:

From here, we can see what the differences made were and also choose whether to commit the new version to the repository.

If we wanted to alternatively see a log of all of the changes that had been made, after opening the /etc repository, we could hit the "Log" button to bring up a listing of all of the commits. From there, selecting any particular commit would bring up a Diff screen showing the changes which had been made:

If we had seen a change which we didn't want and needed to roll back, right-clicking on any previous version and selecting "Revert" is enough to change the file back to it's previous state and update the repository.

Project Euler

Signed up recently to Project Euler, seems like a good way to keep your computer science/programming skills sharp. Although I'm surprised on the forums everyone's using C/Assembly to solve the problems. Got a nice badge auto generated for me as well:

The problems seem like they could get a bit addictive, but definitely a lot of fun and probably better than a spending time on facebook.

How to see which package a file belongs to

Previously I wrote a post talking about how to see what files were installed as a part of a package. In this post, I'll talk about going to other way i.e. how to tell which package a file belongs to

On Debian/Ubuntu you can do so using the dpkg search function:

# sudo dpkg -S /etc/init.d/whoopsie
whoopsie: /etc/init.d/whoopsie

On RedHat/CentOS you can use the rpm command:

# rpm -qf /usr/bin/bash

Configuring boot services

One of the common tasks when setting up a server is to configure whether a service is set to start up on boot or not. This is handled differently on different versions of Linux.

To list all services and whether they're set to run on boot:

RHEL/CentOS/Fedora

chkconfig --list

Debian/Ubuntu

rcconf

NOTE: this program doesn't come installed by default

Enable a service to run on boot:

RHEL/CentOS/Fedora

chkconfig [service name] on

Debian/Ubuntu

update-rc.d [service name] enable

Disable a service from running on boot

RHEL/CentOS/Fedora

chkconfig [service name] off

Debian/Ubuntu

update-rc.d [service name] disable

Tomcat and Virtual Hosts

In this guide I'll go through setting up some very simple virtual hosts on an Tomcat server. This guide assumes the steps gone through to setup Tomcat 6 on Ubuntu as per this previous post.

So, the first step is to define the host under /etc/tomcat6/server.xml:

Put the above line in the Catalina "Engine" section. The "name" attribute will be used as the hostname to match and the "appBase" will define where Tomcat will look for the applications to run off of this host. If you'd like to define some aliases for this virtual host, you can do so with a nested "Alias" directive as described in the Tomcat documentation.

Next, if we want to define the Context we simply create the directory for it under Catalina:

mkdir /etc/tomcat6/Catalina/example.org

And then for a simple application we can just copy the ROOT app from the default context:

cp /etc/tomcat6/Catalina/localhost/ROOT.xml /etc/tomcat6/example.org

This will define the Context for our application. Next, we will need to create the application directory to actually hold our applications for this virtual host and copy the relevant application files to this new directory. This is done with:

mkdir /var/lib/tomcat6/example.org
cp -r /var/lib/tomcat6/webapps/ROOT /var/lib/tomcat6/example.org

Then I modified the "index.html" file under "example.org/ROOT/" to display "example.org" instead of the default "It Works!" so that we would know when the Virtual Host was being accessed. Once this is done, we can go ahead and restart Tomcat in order to apply the changes:

sudo service tomcat6 restart

To test out that this configuration is working, I added a line to my hosts file (/etc/hosts under linux) on my desktop machine to point "example.org" to the IP address of the VM that I had installed Tomcat on. This allowed me to type in http://example.org:8080 and have the request go to the Tomcat server.

If everything worked out well, going to the virtual host at http://example.org:8080 should yield the modified page, where as going to http://[Tomcat server IP]:8080 will result in the default page.

So, there you have it, that's the short story on how to setup up virtual hosts on Apache Tomcat.

Ubuntu - The following packages have been kept back

If you've used Ubuntu for long enough, you'll find that eventually you'll run into a problem when upgrading the installed packages. When running apt-get from the command line, the problem manifests itself as the following:

$ sudo apt-get upgrade
[sudo] password for srdan:
Reading package lists... Done
Building dependency tree      
Reading state information... Done
The following packages have been kept back:
  linux-headers-server linux-image-server linux-server
0 upgraded, 0 newly installed, 0 to remove and 3 not upgrade

The short answer is that you should be able to upgrade by running the "apt-get dist-upgrade" command:

$ sudo apt-get dist-upgrade
Reading package lists... Done
Building dependency tree      
Reading state information... Done
Calculating upgrade... Done
The following NEW packages will be installed:
  linux-headers-3.2.0-27 linux-headers-3.2.0-27-generic linux-image-3.2.0-27-generic
The following packages will be upgraded:
  linux-headers-server linux-image-server linux-server
3 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 51.2 MB of archives.
After this operation, 217 MB of additional disk space will be used.
Do you want to continue [Y/n]?

The long answer comes from the man page of the "apt-get" command. In particular, if you look at the description of the "upgrade" argument, two sentences stick out:

"under no circumstances are currently installed packages removed, or packages not already installed retrieved and installed."

"New versions of currently installed packages that cannot be upgraded without changing the install status of another package will be left at their current version."

Because you can't upgrade the "linux-image-server" (a.k.a. the kernel) without upgrading the headers as well (technically you can, but it can lead to serious problems) it won't let you upgrade them using the "upgrade" command. Either that, or the "new" linux image package requires that a "new" linux headers package be installed, violating the requirement that packages not already installed not be installed.

The reason that the "dis-upgrade" command works, where the "upgrade" command does not is that "dist-upgrade" takes into account dependencies between packages. Also from the man page:

"dist-upgrade ... intelligently handles changing dependencies with new versions of packages; apt-get has a 'smart' conflict resolution system, and it will attempt to upgrade the most important packages at the expense of less important ones if necessary."

This does beg the question though as to why not just use "dist-upgrade" all the time or incorporate the conflict resolution system into the "upgrade" command?

I suspect the answer has something to do with how each "edition" of a distribution is defined. i.e. Ubuntu 12.04 will ship with version 3.1.13 of the "at" package and all other packages that are a part of this "edition" should work with that version. Having many different packages depend on specific versions of other packages could end up in a situation where it becomes very difficult to upgrade any individual package.

svn:ignore property, STS and Subversive

Working with a combination of Springsource Tool Suite, Subversion and the Subversive plugin, one of the things that really bugs me is the issues I keep on getting as a result of messed up source control of the "target" directory.

This directory typically holds all of the compiled classes as well as a stacktrace log and a few other things. In general it never really needs to be put under version control.

One of the things I keep forgetting to do, that frustrates the hell out of me is to set the svn:ignore property as soon as the repository is created. You see, without this property set, the target directory is submitted (added) to version control and once it's in there, there's no (easy) way of getting it out, as the Subversion documentation says:

"...Once an object is under Subversion's control, the ignore pattern mechanisms no longer apply to it..."

And even if you set the "svn:ignore" property on the directory, it still probably won't work properly. Instead committing all of the class files and so forth that you couldn't give two craps about.

All this is well and good, but could be written off as a minor problem, if it weren't for the fact that when you try to revert your changes, Subversion could very well pick up "conflicts" between the class files, and in fact can put you in a situation where you're struggling to get a functional checkout of the repository, simply because of the "target" directory.

The problem seems to be with the nature of the files being stored in the directory being constantly deleted/recreated etc... which seems to screw up Subversion. At the moment there doesn't seem to be a fix for the issue i.e. every time I see the problem, I just manually manage the conflicting files.

Linux Kernel Swappiness

There is a tendency of the Linux kernel to use memory as file system cache. This generally improves performance and is considered to be a "good thing". However, one thing that the kernel also occasionally does is take the memory allocated to running processes and swap them to disk, in order to use that memory for file systems cache. Now, this can and does result in processes becoming slower, especially if they've been running (sitting in memory) for a while, but haven't been actively used.

Luckily, there is a way in which you can define this behaviour and it's called the kernel "swappiness" value. The value has a range of 0 to 100, with zero roughly meaning that process memory will never get swapped out for the sake of disk caching and a value of 100 means that process memory is very aggressively swapped out, in favour of disk caching. A more in depth explanation of how the kernel manages swappiness, can be found here.

By default, this value is set to 60, which is configured more for server throughput, rather than desktop responsiveness.On my desktops I usually set the value to 10, which seems to be a good fit for desktop responsiveness.

The way to set it on Ubuntu is:

$ sudo sysctl vm.swappiness=10

and to make the changes permanent, just add the following line to /etc/sysctl.conf:

vm.swappiness=10