=^.^=

How to Tell What Version of a RedHat-Based Flavour you are Using

karma

It's important to know what version of RHEL/Fedora/CentOS/Scientific Linux/etc. you are dealing with when looking for version-compatible RPMs that are out-of-repo. I always end up forgetting how to do this, so for our mutual benefit:

$ cat /etc/redhat-release
CentOS release 5.6 (Final)

64-bit Ubuntu 12.04.1 Server Virtual Machine Image for Xen, QEMU, VirtualBox etc.

karma

This raw full disk image is a straight-up install of Ubuntu 12.04.1 Server LTS "Precise Pangolin" on EXT3. No packages were selected for installation other than OpenSSH Server. It will boot under full virtualization platforms (QEMU, VirtualBox, VMWare) without modification (except maybe disk image conversion) but the steps below are required to make it play nicely as a Xen Paravirtualized Guest.

db3fb8b154cb05ab704733bba1a6d70e ubuntu-12.04.1-x86_64.raw.hdd.lzma

The user account is "user"
The user password is "user"

The default network settings are: eth0 DHCP

Fortunately, the generic kernel has Xen PV guest support so the required buggery is mostly limited to making the console work. Unpack and mount the image:

# unlzma ubuntu-12.04.1-x86_64.raw.hdd.lzma
# mkdir /mnt/rawroot
# lomount -diskimage ubuntu-12.04.1-x86_64.raw.hdd -partition 1 /mnt/rawroot

The distributed /boot/grub/grub.cfg script will make pygrub throw up. We'll drop this (/mnt/rawroot)/boot/grub/grub.conf file in to override it:

default 0
timeout 5
fallback 1

title Ubuntu, with Linux 3.2.0-29-generic
        root=(hd0,0)
        kernel   /boot/vmlinuz-3.2.0-29-generic root=UUID=a52e9498-44e8-4c0d-807e-903d4e19e204 ro console=hvc0
        initrd  /boot/initrd.img-3.2.0-29-generic

title Ubuntu, with Linux 3.2.0-29-generic (recovery mode)
        root=(hd0,0)
        kernel   /boot/vmlinuz-3.2.0-29-generic root=UUID=a52e9498-44e8-4c0d-807e-903d4e19e204 ro recovery nomodeset
        initrd  /boot/initrd.img-3.2.0-29-generic

Now we need to make a getty load on hvc0, create (/mnt/rawroot)/etc/init/hvc0.conf

# hvc0 - getty
#
# This service maintains a getty on hvc0 from the point the system is
# started until it is shut down again.

start on stopped rc or RUNLEVEL=[2345]
stop on runlevel [!2345]

respawn
exec /sbin/getty -L 115200 hvc0 vt102

We probably want to give our VM a static IP. Edit (/mnt/rawroot)/etc/network/interfaces to reflect:

# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.1.100
netmask 255.255.255.0
gateway 192.168.1.1
dns-nameservers 8.8.8.8

Now we are ready to boot up. Unmount /mnt/rawroot and create a configuration file that looks similar to:

name = "ubuntu"

vcpus = 1
memory = 256
vif = [ 'mac=00:16:3e:ff:00:01,bridge=extbr0' ]
disk = ['file:/xen/ubuntu/ubuntu.hdd,sda,w']

bootloader = "/usr/bin/pygrub"
extra = "xencons=hvc0 console=hvc0"

Ensure the MAC address does not conflict with any existing virtual machines. Assuming the configuration file is named ubuntu.conf run

# xm create ubuntu.conf -c

If everything went well you should be looking at a login prompt shortly after.

Note that if you use cp -ax to transfer the filesystem's contents to a larger image in the future, references using UUIDs in fstab and grub.conf will have to be changed to either reflect the new UUID or the corresponding /dev node (probably xvda1) and GRUB must be re-installed to the MBR.

If you would like to move the contents to a filesystem-only image (no partition table, MBR, etc.) which is much easier to grow than a full disk image you can drop pygrub and externalize the kernel and initrd images then reference them in the configuration file.

Documentary for Dinner: The Vice Guide to the Balkans (2012)

karma

VICE takes us on a quick tour of former Yugoslavian states Serbia, Kosovo and Bosnia to investigate long standing ethnic tensions

Documentary for Dinner: Superpower (2008)

karma

Superpower is an exploration of the emergence and consequences of the United States as the sole world superpower and major imperialist force.

A Rant on the Direction of ClearOS, Apps and the Marketplace

karma

Something about this new "apps" paradigm ClearOS has entered has been gnawing away at my subconcience ever since I wrote my little critique on 6.3. In a post on the ClearOS forum regarding missing IPsec support I think I was able to finally articulate the off-ish smell that has been driving me mental.

kfox:

I can't seem to find the IPsec app for ClearOS 6.3

I see the paid "dynamic vpn" app in the market place and it appears to reference an independent IPsec app.

The Dynamic VPN app is an extension to ClearOS's IPSec VPN app. The service allows IPSec to be used in situations where either one or both of the gateways are on a dynamic IP address issued by the ISP or in cases where instability using unmanaged IPSec tunnels exists.

Herballizard:

http://www.clearfoundation.com/docs/release_info/clearos_community_6.2.0/final_release_information

PITA

kfox:

The unmanaged IPsec tool has been unmaintained for a few years and was dropped in version 6. It's open source, so if someone wants to revive unmanaged IPsec, go right ahead.

Yeah I love the whole "It's OSS, you do it if you like it so much!" attitude at the same time architectural decisions seem to have become increasingly marketing-driven. If it was too much trouble to update the old IPsec module why not cut out all the paid bits of the for-profit Dynamic VPN app? Smells a little fishy.

Maybe I will make it. If you hire me. Unfortunately, I have to put food on the table and the people who pay for my time have very little use for a webconfig interface once I have it rolling. Being someone who has contributed little more than some help on the forums and a couple VM images I wouldn't be so whiny if this wasn't a functionality ClearOS didn't already have at one point.

I'm beginning to question the logic of continuing to use ClearOS when I have to do so many things myself; I'm a Gentoo admin so it goes without saying that I love to do everything myself - but I use this crazy, neat little redhat system because it used to save me countless hours and let me respond to network crises quickly.

It feels like the foundation has cut off its nose to sell its face. A lot of stuff seems to be missing or half baked just so they could roll out this new "Marketplace" paradigm in time for RHEL 6. A paradigm which itself rubs me all sorts of wrong ways.

It's a shame they gambled on buzzword dollars rather than building on an already great platform. I hope I'm dead wrong; that the gamble pays off and we end up seeing a whole bunch of quality third party "apps" from the community but the sad truth is that functionality was always there and we didn't see a whole lot of participation back in the day (and I'm not pretending to have been any help!).

On the surface, it looks like this new app framework was designed mostly with the intent to make it easier for paid services to be integrated. I wonder which kind of apps the Foundation staff members will be focusing most of their attention on now. They certainly don't seem worried about the lack of a free IPsec app despite every crappy embedded router's support for it and highly critical Advanced Bandwidth rules have been bumped two versions (so far!).

Oh well, I know only too well that we all gotta make that dolla. Maybe the corporate makeover (and hopefully increased revenue that follows) is what Clear needs to propel itself to new heights of greatness. I sincerely hope so.

UPDATE You should really read the thread; Dave Loper did a great job of explaining why things have gone this way and what the path forward looks like. I'm a lot more optimistic now.