Archive for May, 2009

Work around ISP QoS limitations

Friday, May 29th, 2009

ISPs which enforce QoS limitations suddenly, without alerting the customer, are abusing their force. QoS limitation is not a bad thing, from the ISP’s point of view, but changing the customer deal without notifying him seems to me to be unfair.

This is a recipe for a QoS workaround.


  • One fast Internet connection which is not used to its full capacity
  • Defined target service provider. I use Giganews as an NNTP, which is the fastest method of obtaining content today. You should have the service list of IPs. Luckily, Giganews use only two IP addresses
  • One “evil” ISP which enforces QoS for external targets
  • One server in the ISP’s hosting farm, which has no speed or transfer limitations, and is probably not bound by the ISP’s QoS
  • For a better looking dish – some graphing solution, such as Cacti or MRTG


  • Setup OpenVPN Server on the hosted server
  • Setup OpenVPN Client on your NNTP/Other service client (your desktop, your Linux router, etc) – This can also be a Windows machine, but configuration varies a bit.
  • Define, in your OpenVPN client.conf line(s) which look like this:

route <SERVICE_IP>

route <SERVICE_IP2>

  • If this is a router machine, activate NAT on it. Of course – remember to set this rule to work after reboot too!

iptables -t nat -A POSTROUTING -o tun+ -j MASQUERADE

  • For your good feeling, try to pickup data from before and after, and compare.
  • Start the OpenVPN Service on the server, on the client, and restart your NNTP/Other service downloads.
  • Serve with a smile :-)

The result dish is both tasty and good looking! see below:


A word of warning – OpenVPN is a VPN tool. As such, it uses encryption and varios methods which are very secure. This means that for high througput, such as mine (about 10Mb/s) you will see the impact on the router/workstation’s CPU. Under virtualization, I get about 2% additional system CPU utilization from a 2x3GHz Xeon CPU. For older router devices this could result in an overworked router. I am so glad I got rid of my old P2 350MHz router in favor of the virtualized one.

LVM Recovery

Friday, May 29th, 2009

A friend of mine made a grieve mistake – partition a disk containing Linux LVM directly on it, without any partition table. Oops.

When dealing with multi-Tera sized disks, one gets to encounter limitations not known on smaller scales – the 2TB limitation. Normal partition table can contain only around 2TB mapping, meaning that to create larger partitions, or even smaller partitions which exceed that specific limit, you have to take one of two actions:

  • Use GPT partition tables, which is meant for large disks, and partition the disk to the size limits you desire
  • Define LVM PV directly on the block device (the command would look like ‘pvcreate /dev/sdb -> see? No partitions)

“Surprisingly” and for no good reason, it appears that the disk which was used completely for the LVM PV suddenly had a single GPT partition on it. Hmmmm.

This is/was a single disk in a two-PV VG continging a single LV spanned all over the VG space. Following the “mysterious” actions, the VG refused to start, claiming that it could not find PV with PVID <some UID>.

This is a step where one should stop and call a professional if he doesn’t know for sure how to continue. These following actions are very risky to your data, and could result in you either recovering from tapes (if exist) or seeking a new job, if this is/was some mission-critical data.

First – go to /etc/lvm/archive and find the latest file named after the VG which has been destroyed. Look into it – you should see the PV is in there. Search the PV based on the UID reported not to repond on the logs.

Second – you need to remove the GPT partition from the disk. The PV will be recreated exactly as it was suppoed to be before. Replace /dev/some_disk with your own device file.

fdisk /dev/some_disk



Third – Reread the VG archive file, to be on the safe side. Verify again that the PV you are about to recreate is the one you are to. When done, run the following command

pvcreate -u <UID> /dev/some_disk

Again – the name of the device file has been changed in this example to prevent copy-paste incidents from happening.

Fourth – Run vgcfgrestore with the name of the VG as parameter. This command would restore your meta information into the PV and VG.

vgcfgrestore VG_TEST

Fifth – Activate the VG:

vgchange -ay VG_TEST

Now the volumes should be up, and you have the ability to attempt to mount these volumes.

Notice that the data might be corrupted in some way. Running fsck is recommended, although time-consuming.

Good luck!

Service account

Wednesday, May 27th, 2009

Assume you have a single purpose account. Maybe some service account, user which should run a single task ever, or even a case of a limited menu interface. You want your user(s) to reach there using SSH because that is the method to do it right and secured. You want it to be easy for the users – combine your ability to have a secure session with ease of use through SSH keys, while fearing an abuse.

You can probably see how this balances. In most cases, it balances as “we will make our users’ life hard and they will have to type a password”, which is fine, except that you hardly ever actually enforce password policy or password age limitations, so you compromise security. Also – you have to trust your users to be nice, and never attempt to test the limits of your system. It’s bad, but finding a simple-to-manage solution for that specific single task you want is so complicated. You even consider (and sometimes actually enforce) chroot environment, which is such a pain to maintain. Either too secure or too loose.

Wow, that was long. The reason for this long prologue is that I have found a very nice utilization for a powerful and capable tool, jailkit, without the fuss of the entire chroot stuff. This is no invention of mine, but it appears to be a feature of this wonderful tool which is commonly ignored for no good reason.

This is the tool called jk_lsh – jailkit limited shell. You can define this tool on a per-user or per-group granularity through editing /etc/jailkit/jk_lsh.ini and changing the settings to match your requirements.

This allows you to use ssh keys for seamless authentication from defined client machines, and with limited set of commands which can be executed. Your job, as a sysadmin, is to make sure that these commands cannot be exploited – don’t let your users write permissions for these predefined commands so they would not be able to override your commands. Don’t let these commands reside on a share, so that replacing the command from another computer will not be possible, etc. Also – use full path for the child commands inside scripts, if used, so that altering PATH directives cannot change how your scripts work. This is quite basic, when you get to think about it.

The bottom line – your script on a remote machine which must run some specific task on this jk_lsh-modified machine can run safely and do only what it was intended to do. Same goes for icons on your users desktops, with a specific ssh command included.

I recommend this configuration – enjoy the benefits of controlled environment without the pain of chroot. That is – if it fits your needs, of course.

Cables connection in Israel for Linux

Thursday, May 14th, 2009

Update to 0.2. Links remain the same. At the moment I cannot host many versions (it’s mostly uncomfortable), but this might change in the future.

I have created a GUI cables installer and configurator for L2TP on Linux.

I have noticed that there is no GUI solution, so, after this has been brought up, I have done it (!!!)

I have uploaded these files here, and you are welcome to use them.

Remember – they are designed for a blank Ubuntu (currently. More distros will be supported in the future, upon request) with not much of junk installed. Also – they are designed for the simple user. Double-click and run. That’s it.

Quoting my readme file:

L2TP Cables connection in Israel (and across the world, where relevant) by Ez-Aton

This is an installer and configurator for L2TP over cables in Israel
With some luck, by running this installer, you will be able to connect
to the Internet with a dialer!

The system assumes you have little technical knowledge of Linux and you
are not expected to have any. Follow the defaults, and you should be fine.

This configuration will be cross distro in the future, meaning it will work
both on your Ubuntu, your RHEL, your Centos, Mandrake, etc. In order for me
to be able to do so, please assist by sending information on systems I am
not familiar with yet, per the appendix at the bottom.
Also, you can feel free to send me info in case the system did not work for
you (and let me know what are the differences from a default installation),
or, as always, send me money.

Visit my technical blog for updates and all kind of other technical stuff, at

OSS work is meant to be based on others work, and that I have done. I would
like to thank (and mention below) the resources for without this would not
have happened.

I hope you enjoy this dialer!


—How to use
Simply double-click on the “cables” icon on your desktop, and the system will
get you connected.
For CLI utilization: Run /usr/local/bin/cables

—Tools and resources used:
To create this package I have used the following tools and resources
xl2tpd by
xl2tpd guide for Israel Cables
ISP LNS list
My connect/disconnect scripts from

This package contents are under GNUv2 license, meaning you have full permission
to modify the contents of this package, except for the binary packages included
with it, where you are binded by their respective licenses.

—My Distro/ISP is not supported!
Well, these things happen. Over 300 distros our there, and I can’t have them all.
However – you have your own distro, right? For me to add it to this package
(assuming you don’t want to do this yourself) you will have to supply me with the
following info:
* What distro, kernel and version, and how you get the distro name
(for example – on Redhat – /etc/redhat-release. On Ubuntu – /etc/lsb-release)
* The file containing the version inforamtion (see above)
* The versions available from your repositories of xl2tpd or l2tpd for older
releases, and where you can get them
* Your ISP, your ISPs LNS names/addresses
* Your country
* All other info you think relevant

—Change log
0.2 – Added ability to enter manual LNS address. Added Orange LNS. Fixed fixroute to allow both IP and hostname without problems. Fixed cables connection script to run fixroute anyhow.
0.1 – Initial release

Download it here:

If you want the scripts and sources (not for the simple user!), you can get there here: l2tp-cables

IBM DS3400 expand Logical Drive (LUN)

Wednesday, May 6th, 2009

I have always liked IBM DS series management suite. I have claimed once that your first storage (and with it – your way of thinking about storage abstraction, I assume) is your favorite storage. I have been using the Storage Manager 9 for years now, even before it was 9 (I think that it was 7 then), and way before it has become 10-something version.

SM9 is the tool to manage the DS4xxx storage series (previously fastT series, if you can remember…), however, their “smaller” brothers, the DS3xxx series have arrived with something else claimed to be “Storage Manager” as well. It has began as SM2, and I was sure surprised to see it under the name “Storage Manager 10″ today.

It seems as if someone wanted to make life easy, so everything is hidden behind some messy-looking dashboard. Finding the so-well-known abstraction logic is almost impossible for me, no matter how many times I will use this disaster of a product. Can’t complain about the storage devices – they are rather good, and although IBM has recently had some firmware issues and stability issues with some of its storage products – I can’t say I hate this device. Storage Manager 2 (or 10, today), however, is something I prefer to avoid.

After all this ranting and crying, I can share this piece of technical information. Storage Manager 10 (2, whatever) does not allow for Logical Drive to be expanded. You can expand the Raid Array – no problem. Just add some more disks to it, however, the free space created in that specific array will not be available for your reallocation pleasure – you cannot expand any of your existing Logical Drives with it.

Google has pointed me to that specific post which enlightened me with a new understanding of the DS series – the SM10, while being nothing more than a limited GUI for the storage-handicap IT persons, does not completely cancel the storage device’s abilities. The device can expand LUNs, so SM10 can allow it, secretly.

You need to know what you’re doing. I will copy/paste the contents of that blog entry for future use:

Expanding LUNs on a DS3000 series disk system:

First make sure you have enough space in your array. Next go to the script editor in the Storage Manager gui. Choose script editor. Type in a command like this:

set logicalDrive ["FINKOPAS01-BOOT"] addCapacity=50GB;

This would add 50GB’s to the disk “FINKOPAS01-BOOT”.

Now choose run command from the menu. After the disk system has expanded your LUN you should see the extra capacity in the disk management console window.

*NOTE*: This information was originally found here:

The target link is dead there, unfortunately, however, the “secret” information is available for all.

Do not forget the semi-comma at the end of the line. It won’t work otherwise. IBM… :-)