Thursday 18 September 2014

XFS on Red Hat Enterprise Linux 6

This is just a quick post. I've used the XFS filesystem on many, many Linux hosts for a great many years now. I've used it on CentOS6 since that OS was first released, and XFS is now the default filesystem for RHEL7.

Yay, XFS Logo

So, I went to make a new XFS filesystem on a new Red Hat Enterprise Linux 6 system in the past week, I more than a little bit surprised to find that XFS is not shipped as part of the base OS. More than that - it is simply not installable/obtainable without paying an extra subscription fee per host/CPU. (How did I not know this after 4+ years of using this OS??). So, I pay for an OS, and consequently I get less than if I had chosen a free equivalent?

At first I thought I was wrong, but no, XFS which is mainline-kernel, the base-default in RHEL7, and available in all downstream free versions of RHEL, is simply not built into the base of RHEL6 (and 5 and below, for that matter).

Or is it?

'locate xfs' shows that the kernel modules are actually shipped within the default RHEL6 kernel. So, in that case, what then does one get for one's per-CPU licence fee? Answer: the filesystem utilities such as mkfs & dumpfs. The base system is more than capable of reading & supporting and XFS filesystem, it just can't make a new one.

So, if you find yourself in such a position, there is a clever way around this. Whilst will doubtless invalidate your RHEL support agreement, which, let's face it, is what you are paying for*, this is quite easy to do, so why not do it?

* Yes, this is clearly a self-defeating argument.

Simply download the latest xfsdump and xfsprogs RPM packages from your friendly local CentOS repository and install them on your shiny newly-invalidated RHEL box, and you can make as many XFS filesystems as you wish!

Other clever ways include:
  • Typing "yum install $URL1 $URL2" for the above two .rpm URLs
  • Typing "yumdownloader xfsdump xfsprogs" on a CentOS6 box and copying the packages across to the RHEL6 machine.
  • Install CentOS
  • Install RHEL7 (or CentOS7)
Depending on what you need the FS created for, you could even choose to remove said packages, and re-validate your RHEL Support.

And if Red Hat asks, I didn't tell you this.

Monday 15 September 2014

CentOS 6 to CentOS 7: Upgrade of my Desktop

Deciding that the best way to learn a system is to use it, I recently decided to move my primary Desktop system at work from CentOS6 to CentOS7. This is the story of that upgrade.


Running the Upgrade Tool


So, after some planning and system prep work, I ran the CentOS upgrade tool. This caused me many false starts - including the fact that my system had been Oracle Linux at one point in it's life, and the CentOS upgrade tool didn't like the OEL packages. So I tried to change the offending OEL packages to CentOS ones, which included the sterling idea of removing glibc from my system's rpm database [Hint: don't do this, or if you really feel that you have to, do remember to type "--justdb" in the command, unlike me who knew to type it but left it off the actual command I executed, and thus accidentally removed glibc from a running system, which was not the best scenario]). I did discover wonderful commands such as "yum distro-sync" which will prove invaluable in years to come, but was a lot of heartache in between.

After such small starter issues, I got the upgrade tool to recognise my system fully, so I ran the prechecks and then ran the actual upgrade itself... at which point it outright failed. The upgrade tool refused to upgrade, since I had Gnome installed. So, I "yum remove"d GNOME (as per Red Hat KB) and continued.

After The Fall, Comes a Reinstall

So, the upgrade tool dutifully upgraded my system - and left me without a working GDM login screen (which I couldn't fix, since I don't know the inner murky depths of systemd), broken /var/log/ output files, and quite a few more elements that should have worked on a cleanly-installed system.  So, after all of the above travails, I decided to simply reinstall. Noone else on the internet appeared to have my gdm problem, except two others (on Fedora) who also reinstalled after their failed upgrades. It would have saved me many, many hours if I had just done this in the first place.

...Except Now I can't Reinstall Either

So I booted the Install DVD, ran the installer... but this then failed to install on my system.

I hit the issue "you haven't selected a bootable stage 1 partition" in the disk partitioning installer section -- the installer decided that my hard drive needed to be GPT instead of MBR format, but instead of telling me this, it decided to hit me with unrelated errors telling me I had did not have a boot partition (when I did).

See here for resolution for this issue: http://fedoraproject.org/wiki/Common_F20_bugs#UEFI_install_to_ms-dos_.28.27MBR.27.29_labelled_disk_fails_with_unclear_errors

So I had to convert my disk to GPT and re-run the installer. It ran easily after that, it was mostly a boring straightforward affair that someone else can blog about.

I saw someone else at work also hit this issue, but they simply blew the whole disk away and let the installer do it's own thing -- I wanted to do something silly, like keep the existing data I had on the drives without a reformat (yes, I had backups elsewhere, but that's not the point).

So, I finally get to Reinstall... and GNOME needs a lot of help

So much help, that  I posted about it here.

On CentOS6, I used Gnome2 as my primary desktop interface, so Gnome3 seemed like a logical thing to move to. With a decent amount of research and effort, I actually quite like it now. My link shows what I changed to make it feel like home.

Other System Stuff

# Install EPEL
yum install -y epel-release --enablerepo=extras
yum upgrade -y epel-release
# or manually:
yum install http://fedora.mirror.uber.com.au/epel/7/x86_64/e/epel-release-7-1.noarch.rpm


# Install ElRepo (for NVidia kernel)
yum install http://www.elrepo.org/elrepo-release-7.0-2.el7.elrepo.noarch.rpm

# Install Chrome (as per http://www.if-not-true-then-false.com/2010/install-google-chrome-with-yum-on-fedora-red-hat-rhel/):
cat << EOF > /etc/yum.repos.d/google-chrome.repo
[google-chrome]
name=google-chrome - \$basearch
baseurl=http://dl.google.com/linux/chrome/rpm/stable/\$basearch
enabled=1
gpgcheck=1
gpgkey=https://dl-ssl.google.com/linux/linux_signing_key.pub
EOF
yum install google-chrome-stable



# Install "nux desktop" for vlc
yum install http://li.nux.ro/download/nux/dextop/el7/x86_64/nux-dextop-release-0-1.el7.nux.noarch.rpm

# Install vlc from Nux
yum install -y vlc


# Disable "nux desktop" from being auto-enabled
cd /etc/yum.repos.d/
sed -i.orig 's/enabled=1/enabled=0/' nux-dextop.repo




Nvidia Drivers - The Easy Way!

# Install ElRepo repo above
yum install nvidia-x11-drv nvidia-detect kmod-nvidia
reboot




Gnome 3 on CentOS 7 - How I Made It Lovely and Usable

I generally really liked Gnome2 in RHEL6 - it was stable and worked well, and it's shortcomings had been largely addressed over the years. I promised I wouldn't fall prey to everyone else's griping about GNOME3 - but it's quite hard not to. For example, I have to use the command line to configure many of the GUI settings - Seriously??

I won't whinge too much, I'll just record what I've had to do to make Gnome3 a nice place to be. After a flurry of several days' activities, summarised below, I actually really quite like Gnome 3 now, I just don't understand the defaults and/or design decisions behind them.

Starting out in Gnome 3

This picture does sum up what it first felt like to use Gnome 3 after many years of Gnome 2:
http://i.imgur.com/IIBxZm6.jpg

But what I ended up with is something far more like:

So how did I get to the point of a personal tick of approval?


Install some packages, configure the GUI from the command line:

# Key Gnome Tools: dconf editor, Extensions browser plugin, a menu editor and the all-important Tweak Tool
yum install -y dconf-editor gnome-shell-browser-plugin alacarte gnome-tweak-tool

# Update Firefox to v31.0, updated from v24 since RHEL7 was shipped
yum update -y firefox

# Install Gnome's Epiphany "Web" Browser to browse Gnome Extensions. Only needed if you# Set the screen timeout to 60 minutes, which cannot be done via GUI options
# Configuring a GUI via the command line - seriously?
gsettings set org.gnome.desktop.session idle-delay 1800

# Replace the system Firefox packages with the latest ones from the internet (to run Firefox-current instead of -ESR):
yum install -y http://mirror.internode.on.net/pub/fedora/linux/releases/19/Everything/x86_64/os/Packages/e/epiphany-3.8.2-1.fc19.x86_64.rpm


Install Gnome Extentions:

Open https://extensions.gnome.org in Firefox browser, and install the following extensions, which are essential for desktop usage:
* Activities Configurator (to adjust top-left hot-corner timeout)
* Impatience (to adjust animation speeds)
* Frippery Panel Favourites (to put application-launch icons in the top panel)
* WindowOverlay Icons (Application Icons on each application preview in the Overview overlay)

Optional Extensions, for personal taste:
* Removable Drive Menu (Allows eject of removable devices from top panel)
* Caffeine (adds a button to top panel to disable screensaver/screen-power timeout; useful for a workday)
*  Lock Screen (adds a lock button to top panel, to allow single-click screen lock)

Now open the Gnome GUI Tweak Tool:

* Configure  Shell Extensions/Activities Configurator, adjust HotCorner Sensitivity to 200 (as per http://stevenrosenberg.net/blog/desktops/GNOME/2013_1209_gnome_3_hot_corner_sensitivity)
* Configure Theme: Turn on Dark Theme for all applications
* Configure Shell Extensions/Impatience: Adjust to scale 0.65 (Gnome default is 1.0)
* Configure Fonts: Set Default font to "DejaVu Sans 10"
* Configure Desktop: Set background Picture URI to "Sandstone.jpg" (or something else you like)

Edit the "Favourites" Application List:

This list appears in multiple places, in the same order. This appears as Favourites in the "Applications" menu in the top Panel, and as the icons used in the "Frippery Panel Favourites", and as the menu in the Overview overlay. So, to edit it, use the following steps:

* Press the Windows key on your keyboard (aka Super,  Meta key) to get the the Overview overlay
* Right-click on each app in the left side-menu you don't like & remove it
* Now open the Show Applications (nine white dots) icon
* Right-click on each application icon & select "Add to Favourites"
* Drag the Order  of icons up & up as you please

The order appears in all areas (Panel favourites, Applications->Favourites) which I really like.

Install a Firefox Extension to hide the title bar:

Open Firefox, and install the extension "Htitle" - this hides the top title bar when in full-screen mode, and gives you back quite a bit of screen real estate.

...And You're Done

And after that you have a very lovely, workable Gnomey system!



Bonus Marks: Make the Dark Theme More Pervasive

Ok, this is more personal taste than bonus marks. I definitely prefer the Adwaita Dark Theme for Gnome (which is just a dark version of the default Gnome3 theme), which is quite easy to turn on (in the Gnome Tweak Tool, as listed above).

However, once you enable this, eagle-eyed- (and not-so-eagle-eyed- and even blind-) people will probably notice that some Gnome apps don't look all that Dark when using the Dark theme, and thus look quite out of place. This doesn't make sense, until you know that while many apps are now written in Gnome's windows-drawing library GTK3, some are still using the older GTK2, and the older apps don't utilise the Dark theme. It is also possible for some gtk3 apps to override the dark theme choice, although this is less of an issue than the gtk2 apps.

So, to fix this, we somewhat follow the instructions in this link, albeit reversed (thanks to this answer for pointing me there), and then add gtk-2.0 goodness on top of it all (thanks to this guy for the gtk-2.0 dark theme).

mkdir -p ~/.themes/Adwaita
cp -rp /usr/share/themes/Adwaita/gtk-* ~/.themes/Adwaita
cd ~/.themes/Adwaita/gtk-2.0
wget http://pastebin.com/download.php?i=vbnULbyi -O gtkrc-dark
ln -sf gtkrc-dark ./gtkrc
cd ~/.themes/Adwaita/gtk-3.0
ln -sf gtk-dark.css gtk.css

And also, installing and using the Firefox theme "FT DeepDark" also makes it blend in much better with the Dark theme.

Update: the latest release of Firefox theme DeepDark is no longer compatible with Firefox 31.x - you will need to install an older version. See here for older versions, version 11.1 is still compatible.


Friday 5 September 2014

Importing a SSL Wildcard Certificate from an Apache Webserver onto a Cisco ASA 5500

I recently needed to use the same wildcard certificate on both a Linux Apache host (Apache 2.2, RHEL6) and a Cisco ASA (5505), and this is how I did it. This blog post starts _after_ I have the certificate generated, signed, installed, working & tested on the Apache host (which was just a standard CSR + install process, documented in thousands of places elsewhere on the web).


Note: This is a direct-copy rip off of another blog post (http://blog.tonns.org/2013/02/importing-ssltls-wildcard-certificate.html) - I don't really add or change much compared to that post (aside from notes on the way), as the steps worked fine for me; I'm just replicating it here for posterity in case that blog goes away.
Here are the steps:

1. Convert all certs and keys to PEM format


    mkdir asa
    openssl x509 -in example_com.crt -out asa/example_com.crt -outform pem
    # See note below re:next step for intermediaries 
    openssl x509 -in geotrust-intermediate-ca.crt -out asa/geotrust-intermediate-ca.crt -outform pem
    openssl rsa -in example_com.key -out asa/example_com.key -outform pem
  

Please note that your certificates may well be in PEM format already - if so, you only need the key conversion step and use the original certificate files.


Please also note that the intermediate-cert step above actually cut the number of chained certificates in my intermediary's cert file, from the original file's 3 chained certs down to 1. This wasn't some kind of clever amalgamation - the command simply only wrote out the first link in the chain. I'm pretty sure this would have been broken if I imported the new file; I didn't investigate this much though, as I realised that the original certs were already in PEM format, so I just deleted the newly-created file and copied the old one in.


2. Now bundle them into PKCS12 format


    cd asa
    openssl pkcs12 -export -in example_com.crt -inkey example_com.key \
        -certfile geotrust-intermediate-ca.crt -out example_com.p12
    # you will need to choose an export password, when prompted

3. Now base64 encode it for the ASA (to paste into terminal window)

    ( echo -----BEGIN PKCS12-----;
      openssl base64 -in example_com.p12;
      echo -----END PKCS12-----; ) > example_com.pkcs12
      cat example_com.pkcs12

4. Import the cert into the ASA terminal via copy/paste from the above cat output

    fw1# conf t
    fw1(config)# crypto ca import example_com-trustpoint pkcs12 {exportPassword}

    Enter the base 64 encoded pkcs12.
    End with the word "quit" on a line by itself:
    -----BEGIN PKCS12-----
    { snip }
    -----END PKCS12-----
    quit
    INFO: Import PKCS12 operation completed successfully
    fw1(config)# exit
    fw1# wr me
    fw1# show crypto ca certificates

4. Enable the trustpoint on the outside interface

    fw1# conf t
    fw1(config)# ssl trust-point example_com-trustpoint outside
    fw1(config)# exit
    fw1# wr me
    fw1# show ssl

5. Bounce the VPN

    fw1# conf t
    fw1(config)# webvpn
    fw1(config-webvpn)# no enable outside
    WARNING: Disabling webvpn removes proxy-bypass settings.
    Do not overwrite the configuration file if you want to keep existing proxy-bypass commands.
    INFO: WebVPN and DTLS are disabled on 'outside'.
    fw1(config-webvpn)# enable outside   
    INFO: WebVPN and DTLS are enabled on 'outside'.
    fw1(config)# exit
    fw1# wr mem



Please note that the method above involves exporting the server's private SSL key as well the certificate - this isn't quite as secure as having individual certificates with individual private keys for each server.

This SSL certificate's licenced rights covered this use-case (not all registrars do), but the registrar's SSL-management web interface provided no actual way to implement this right. This method is therefore not quite as nice as individual certificates, but I had no other choice.