Tag-Archive for » script «

Wednesday, March 25th, 2009 | Author:

I finally got Ignite Realtime‘s Spark to work. I don’t particularly like Spark – its a necessity though and I’m sure others have had trouble with it.

As some readers might be aware, I’m using 64-bit Arch Linux. Spark runs on top of a JRE, independent of the base platform. Therefore, this shouldn’t be an issue. However, Spark appears to come bundled with a 32-bit JRE.

After a lot of hassle, I eventually figured all I had to do was obscure or remove (rename or delete) the bundled JRE. This way, Spark’s startup script wouldn’t find the bundled JRE and it would be forced to search for the one built into the system. I had previously installed openjdk, an open source JRE from Arch’s [extra] repository.

There also happens to be a minor bug in the startup script in that its looking for a folder called “windows” when there’s clearly no such folder except one named “linux”. Go figure.

Anyway, here’s the gist of the installation if you’re doing it manually on 64bit and you already have a JRE (such as openjdk) installed for your system:

mkdir -p ~/src
cd ~/src
wget http://download.igniterealtime.org/spark/spark_2_5_8.tar.gz
tar -zxvf spark_2_5_8.tar.gz
mv Spark/jre Spark/jre.not
sed -i 's/\/lib\/windows/\/lib\/linux/g' Spark/Spark
sudo mkdir -p /opt
sudo mv Spark /opt
Wednesday, March 18th, 2009 | Author:

[edit] So much for that. It turns out that openssl is able to determine that the key and certificate are already in a single file. Therefore, no csplitting required (well, I hope somebody reading this at least learned about how nice csplit is). In fact, the whole script might as well be obsolete… blaargh. Well, at least it gives a nice warning about not giving a blank passphrase. 😀

Here’s the new version:

pem2pfx – converts a .pem-formatted file containing a private key and signed certificate into a Windows-compatible .pfx certificate file.

#Tricky - brendan@swiftspirit.co.za
# Converts a .pem certificate file to .pfx format
# $1 is the source file
set -e
if [ $# = 1 ]; then
  outputfile=`echo $1 | sed 's/.pem$/.pfx/'`
  echo "Please specify a password below. Windows refuses to import a .pfx certificate with a blank password."
  openssl pkcs12 -export -out $outputfile -in $1
  echo "pem2pfx - converts a .pem formatted private-key and certificate file to an IIS-compatible .pfx file."
  echo "Usage: pem2pfx inputfile.pem"


Thursday, January 01st, 2009 | Author:

Apparently, what operating system you use can say a lot about you. If you’re using some form of *nix, which distro you’re using can say a lot as well. Redundancy aside, I believe that a Linux distribution depends absolutely on its package management and distribution system.

I liked apt-get (1, 2) but there was some technical problem at some point and it caused me to use aptitude instead. Using aptitude is slightly easier – it has more features automated into single, logical, commands where apt-get requires separate commands. Aptitude also has a curses-based GUI. If you’re not using the GUI then, other than brevity in terms of number of commands to learn, there is apparently no technical reason to prefer one over the other. Aptitude and apt-get serve K/X/Ubuntu and Debian well. From this point, I use the names Kubuntu and Ubuntu in a loosely interchangeable fashion.

In my use of CentOS (based on Red Hat), I’ve found I like yum. It seems to work in much the same as aptitude – one command to rule them all. It has some rather annoying default behaviour I’m not going to get into here as its most likely because I’m just not used to it. At least from a technical perspective, it is very good. I believe that Fedora also makes use of yum though my experience with Fedora is very limited.

the theory…

Fedora and Ubuntu are in a class of distributions that have a fairly rigorous release cycle. Ubuntu 8.10 (the version is named so for the year and month of its release) will not, except for major bugs and minor changes, have another major update until the next version, Jaunty Jackalope. Ubuntu users have the latest versions of most software on their desktops right now. In the months preceding the next release, however, they’re not going to be so lucky unless they like using “beta” releases. As I’m not very familiar with Fedora, I’m not going to bother going into its release cycle.

These 2 distributions are also within a class of distributions known as “binary” or “binary-based” distributions. This means that when you download an update, the files that are downloaded are precompiled and should run on any “supported” hardware. This isn’t specifically optimised for your desktop’s hardware, for example, your processor. Perhaps you have an AMD processor which has extra instruction support which Intel CPUs do not have. The reverse could also be true. For this reason, a binary-release distribution cannot optimise for one particular brand of hardware. Regardless of this “non-optimisation”, it should run at a decent pace.

the practice!

About 2 years ago I started using Kubuntu. After a few months of working with it, I started to learn more about its specifics. I’m not much of a fan of using GUI tools to update the system when, ultimately, its all happening on the command-line anyway. The GUI tools just hide the complexity I don’t mind seeing.

I ended up making a bash script, update, which would run all the steps required to get aptitude to just go ahead and upgrade already, kthx?©, perhaps stopping along the way to back up my configuration, remount the NFS network share where we keep an on-site repository, back up the local cache of aptitude’s installed packages, do some folder-link shuffling to use a local copy if the network share couldn’t remount, sync between the local copy and the network share if the previous update had a network share issue, and update lists of packages in the repository. In general, it wouldn’t go ahead if there were any errors though, as you can tell, this script became a messy beast that went above and beyond the original requirements. It worked well for me.

Until the day came to update between Kubuntu 6.10 to 7.04. I did this manually though, not with the script.

I ended up reinstalling from scratch as a result of the mess that ensued. At least, as a backup administrator should do well to demonstrate, it was easy to recover everything I really needed. 🙂

What else is out there?

Even before I had to reinstall Kubuntu, I was introduced to another distribution called Gentoo. There are 2 very distinct differences between Gentoo and Ubuntu’s update system. The first is that Gentoo is a source-based distribution. This means that when you update a package, the package manager downloads the source and compiles everything, hopefully optimising it for your system. This, I think, is very cool. The downside to this is that compiling everything takes a very long time.

Here are my (very unscientific) estimates for the length of time it takes to install a basic GUI OS to a desktop from installation media, excluding extraneous drivers (for example, the latest 3D graphics drivers):

OS: min – max (median)

Windows Vista: 15 – 30 (20) minutes

Ubuntu: 15 – 40 (20) minutes

Gentoo: 3 – 40 (6) hours

Gentoo also requires much tinkering with the config files in order to get things working – this is another reason for the extremely long delay between inserting the CD and booting your awesome* new desktop. Popular applications have binary packages available for download – though this isn’t a default option.

They see me rollin’

There is one more very important distinction Gentoo has from most other distributions. It is a “rolling-release” distribution. This means that there isn’t any rigorous version or “release” that the distribution adheres to. If you install Gentoo today… if you finish installing Gentoo today, you’re probably going to have the latest version of all the applications you installed. If some obscure application gets a major update tomorrow, within a few days, if you update your system, you’re going to have that latest version on your desktop.

The difference between this rolling release and the “other” distributions is rather staggering. For example: If KDE 4.2 were to be released tomorrow, you’d probably have to wait less than 2 weeks for it to be available on Gentoo. Ubuntu users might have to wait till 9.04 – that’s a 4-month wait.

Something more suitable?

Personally, I’m not willing to put in the 40 hours of effort to get my system working the way I want it to. My colleague had to reinstall recently for some obscure reason and it turns out he wasn’t willing to put in the 6 hours (he’s more experienced with Gentoo) of effort to get his system back to how it was running either. Instead, Arch Linux caught his eye. Arch Linux is a rolling-release (like Gentoo), binary-based (like Ubuntu) distribution. Its packages (well, the vast majority of them) don’t need much tinkering with their config files to get things working nicely either. Its the best of both worlds!

You still need to know what you’re doing* but if you’ve come to this juncture, it shouldn’t be such a giant leap of faith. Arch Linux’s package manager, called pacman, has built-in dependency and conflict handling. I use another package manager, yaourt (French for yoghurt), which has very quickly become popular with Arch users. Yaourt enhances the functionality of pacman by allowing you to download and install applications directly from the AUR, or Arch User Repository. This repository contains scripts that allow you to automatically download and install many applications that would otherwise be completely unsupported by Arch’s own core developers. It downloads and compiles the package into a chroot’d environment. It then packages the chroot’d environment into a pacman-compatible package tarball and uses pacman to deploy it into your system.

Also, the AUR supports a voting system whereby popular packages get placed into the more official [community] repository. Yaourt also supports an automated voting mechanism whereby, after installing a package via AUR, it asks if you want to vote for its inclusion in [community].

I estimate that the time taken for my Arch installation was about 90 minutes. I don’t recommend Archlinux for newbies though I do recommend it for any Linux user who’s gotten bored with other distros – and wants to get into the nitty gritty without having to install Linux From Scratch. Arch Linux has been getting pretty popular these days. Its currently at number 14 on Distrowatch.

* IF you know what you’re doing. AND YOU BETTER BLOODY KNOW WHAT YOU’RE DOING!
Tuesday, November 11th, 2008 | Author:

I sometimes use a simplified remote desktop script I built a long time ago, before KRDC and its kin came about. It is still useful for if you normally only connect to 1 server at a time or you want your screen’s real-estate back. Feel free to adjust the defaults. 🙂

This works for generally any distro as long as you have rdesktop installed:

((pacman|yaourt) -S|emerge|(yum|aptitude) install) rdesktop

Copy the text into an appropriately-named file in your ~/bin/ folder. Then chmod it to be executable and link the second alias.

tricky@swiftspirit:~$ [ -d ~/bin ] || mkdir ~/bin
tricky@swiftspirit:~$ nano ~/bin/rd
tricky@swiftspirit:~$ chmod +x ~/bin/rd
tricky@swiftspirit:~$ link ~/bin/rd ~/bin/rdc

Also, create a folder at /media/rd that is writable only by root but readable by anyone. Then also create a second folder within this which is writable by anyone. The /media/rd folder is shared with the remote desktop when you connect so it is useful to keep small scripts or applications that you might install or need often in this folder. The /media/rd/honey folder is there for security purposes so that you can copy content to your desktop but ALSO so that a virus-infected server doesn’t infect your existing executables and scripts in the main /media/rd/ folder:

tricky@swiftspirit:~$ sudo mkdir /media/rd
tricky@swiftspirit:~$ sudo mkdir /media/rd/honey
tricky@swiftspirit:~$ sudo chown -R root:root /media/rd
tricky@swiftspirit:~$ sudo chmod 755 /media/rd
tricky@swiftspirit:~$ sudo chmod 777 /media/rd/honey

copy rd’s content from here.

Once this is in place, to connect to a server, type the command into your terminal from within your GUI:

tricky@swiftspirit:~$ rd my.server.swiftspirit.co.za

If you want to connect to a console session (session 0), use the rdc version:

tricky@swiftspirit:~$ rdc my.server.swiftspirit.co.za

Improvements and suggestions are welcome. I’d built a version which could save your passwords into a shadow file using openssl however I never quite got it to work. Maybe another time. 😉

Category: linux  | Tags: , , , ,  | Leave a Comment