Linux Coaching tag:linuxcoaching.ie,2009-03-30:/linux_coaching/1 2012-01-16T08:20:34Z Making Open Source Software Work For You. Movable Type 4.25 Revealing the Secrets of Email Encryption tag:linuxcoaching.ie,2012:/linux_coaching//1.38 2012-01-16T08:01:26Z 2012-01-16T08:20:34Z Do you know how modern email protection works? Not really? You are not alone. For a simple picture of email encryption most people think of a box in which they place their message that can be locked with a... Ralph http://kerry-linux.ie Do you know how modern email protection works?
Not really? You are not alone.

For a simple picture of email encryption most people think of a box in which they place their message that can be locked with a single key. Once the message is in the box and the box is locked, it can safely be handed over to someone (the mailserver) taking care of the transport to the intended recipient. This simple picture is not too bad because, in a way, that's what happens. But on the other hand this picture is fundamentally misleading to understand how email encryption really works. In other words, the reality is different.

If you follow this simple model alone, and many of us have no alternative, chances are, that you will make dangerous mistakes when you use email encryption or that you simply don't know how to use it. And that is not your fault.

Let me help you understand the basic idea behind modern email encryption to get a realistic picture of how it really works. A picture, that can lead you to do the right thing and to know why.

Why is the simple picture fundamentally misleading?

Because modern email encryption has two very different boxes used to lock a message. You probably haven't heard of the other type of box yet. But the second one plays the most important role in the whole process.

The Ordinary, Single-Key Box

Of course, there is a place for the ordinary box in email encryption that can be locked with a single key. In the real world such a box would come with a pre-fabricated key attached when you buy one in the shops. But the single-key box for email encryption works a little bit differently. You can buy a single-key box without a key and pick any key afterwards in a way you like, because a key is only a very, very large number. Once you lock the box with the key you have deliberately chosen (and nobody knows which one you took) the internal mechanism of the box changes in a way that this box (once locked) can only be opened with the same key or a copy of the same key. The experts today call this box the AES-box and the number you've selected the AES-key.

Well, the message locked in the box is ready for travel and the recipient receiving your locked box will only be able to open it, if he has a copy of the key you used to lock it.

I'm sure you see the problem that arises here. How would your partner on the other side know the key? Without the key it will be impossible to open the box.

That's a really hard problem, because you cannot attach the key to the box or send it with another courier. The key has to reach your partner in a safe way, or all security is lost.

The Invention of a Double-Key-Box

Some three and a half decades ago three clever guys invented an entirely different kind of box that revolutionized the digital world. The new box opened up new possibilities that were unthinkable before. I admit, there is no real-world example of such a box and that may be the reason why most people don't understand what they do when they use this kind of box in practice. And we all do use it when we surf the internet. Believe me, everything we do today to secure our online life is based on this new double-key-box. Paying credit to the inventors, experts call the new box the RSA-box.

How Does the Double-Key Box Work?

You can put a message into the box and lock the box with one key that you own. But once you've locked the box with this key you cannot open it with this key again, it remains locked. The only chance to get the box open again is to use a second key, which is a totally different one but which is related to the key used to lock the box. Both keys form a tightly bound pair where one key can undo the locking done by the other.

For email encryption those double-key-boxes are used to make sure that only one person is able to open the box, the recipient of your encrypted message.

But there was a problem, do you remember? You cannot send the key across the world together with the locked box.

Well, actually you can, and the message in the box will remain secure, too.

Sounds like a miracle? No, not at all, we now have double-key-boxes.

Imagine, you can make copies of your keys very easily. After all, keys are only large numbers. For email encryption to work properly, all you have to do is, make a key pair and circulate copies of one of your keys to everyone who may wish to send you an encrypted email. There is no risk in sending one key (the public key) out into the world so that everyone can get a copy. As long as the other key (the secret or private key) remains secret, all is fine. The secret key, on the other hand, has to be guarded as carefully as the crown jewels. If it falls into the wrong hands, all is lost (again).

What is really going on?

Before we can start to encrypt a message we have to get the recipient's public key. If we don't have it, we cannot do anything. I suppose you know why? To prepare our message for safe travel, we want to use a double-key-box and lock it with the recipient's public key. In doing so we make sure that the only person that would be able to open the box will be our partner, because only he has the corresponding secret key.

And what would he find inside the box after he has opened it? I bet you will be convinced that he will find our message inside. But no, actually he will find a key for a single-key-box in which we have placed our real message for travel together with the double-key-box. With this clever trick we have solved the problem of safe key transmission.

But only if we have used the correct public key to lock the double-key-box. If we happen to select the wrong public key, we are going to make a dangerous mistake. Not only will we give someone else the ability to open the box unintentionally, but we also prevent the intended recipient from reading our message. We are doing the complete opposite of what we intend to do, and we do not recognize that we've done something terribly wrong.

I hope, understanding the crucial part of the double-key-box will help you to avoid such terrible mistakes when you use email encryption in future. Now that you've come to terms with the basics of email encryption you will be immune to making silly mistakes, so go ahead and use email encryption.

]]> Can Online Services Be Secure? tag:linuxcoaching.ie,2011:/linux_coaching//1.33 2011-06-15T21:14:50Z 2011-06-16T07:41:37Z Certainly not, if you store credit card information or passwords in clear text on the servers. Recent data theft disasters have shown, that it is not enough to operate a "secure server" and leave all customer's information unencrypted on this... Ralph http://kerry-linux.ie What's even worse, your customers have entrusted you with their data believing that operating a secure data center will be sufficient to protect their personal data from falling into the wrong hands. It's time to destroy this false belief.

Almost everything you'll learn to know about why you can trust an online shop or an online service provider boils down to the fact, that they make every possible attempt to secure their servers in the data center with all available bells and whistles of modern technology. But there is very little information - if any - about how they treat your data when it is stored on their secure servers online.

Of course I honestly value every effort to make online servers as secure as possible, but on the other hand I am convinced, that securing your online servers alone is not good enough. Let me explain.

A secure server is not invincible

Today most online services use a scripting language and a database server (think PHP plus MySQL for instance) and sensible information goes into a database. Usually the access to this database is given to every program that knows about the database password and normally runs on the same computer.

   It's a complete miracle to me, why after a default installation of some online shop applications the database password is stored in a file that could be read by any user on the system. It seems to be a commonplace belief that the server running the online shop is invincible, and therefore it poses no problem to store a database password in clear text without any additional protection. As we should know by now, secure servers are not always invincible and storing customer data unencrypted is a very bad idea. Not every online service is that careless about database passwords and it's easy to restrict access further, but today it seems to be the norm to dump the responsibility for the protection of customer data onto the administration personell in the online data center.

I wish to make the point, that we have to create online services in a way that if something goes wrong - despite the care to prevent this - customer data inside the online service is still protected against exploitation by intruders. And I'm convinced that such a protection is not only possible but absolutely essential if customers want to use online services securely.

Security and Convenience - Choose one.

As a consequence I'm sure that we have to correct another common misconception. You cannot have both, security and convenience in the online world. Forget it, you have to dump your notion of an easy, hassle-free, automatic and secure online service. Choose one or the other, you cannot have both.

That does not mean that secure online services have to be a pain in the neck but it certainly means that some procedures that have been introduced to make a customer's online experience "smooth", "seamless" and "easy" have to go if an online service that stores credit card information will ever be secure. Without knowing why, online customers will always think that some (unknown) data center professional is the right one to fight security problems, because after all they are in charge to make sure everything runs well. So it's vital that the ordinary online customer knows why some features of online services cannot remain the way they are today.

In their efforts towards making the online customer's life as uncomplicated as possible some vendors have started to encrypt their customer's sensible information. That's fine. But if you store the encryption key in a file next to the encrypted database, it's a little like locking your door and hiding the key under the door mat. This clever idea was born out of necessity, of course. As online customers demanded automatic payment from their online services there had to be a way that a program on a secure server could access the encrypted data (CC info for instance) without the intervention of a human being. The idea of storing the encryption key in some way on the server had been invented originally to ease the pain of the online customer.

If a customer wants to sign up to a service in the middle of the night (very convenient) the customer's data can either be stored in clear text (a bad idea) or, if it has to be encrypted, the key must be available to the web server program on the secure server (another bad idea). Surely, if you go fighting a bad idea with another bad idea, you'll never end up with a secure online solution.

Before you come to the conclusion that there cannot be a secure online service, let me tell you what I've learned during the last couple of months, while I tried to learn something from the data theft disasters and created a secure online service for small businesses, the secure online bills.

Secure Online Bills

An online service has to protect a customer's data even if there is an intrusion into the secure server, this is the fundamental principle that determined the design of my online service. It's really not easy to follow this principle at all times, because while I coded the system, I tried not to burden the user with avoidable inconveniences. But writing every single line of code myself made it clear to me that there have to be some decisions that will make the user's life a little bit more complicated. And it is inevitable, if the system should be secure.

I know, the last thing a customers wants is complications, "easy" is the marketing word not "complicated". But it became clear to me that there had to be more human intervention in the process if it should ever become more secure. So it is not complication that is inevitable. It's the introduction of the human factor into the process that makes it more reliable and secure.

What we need is more human intervention and less automation. I'm sure that if you begin to see, why it is necessary to rely on the informed decision of a human being instead of an automated web server process, the loss of convenience will become totally irrelevant. Making online services more human is the way to go, that's what I've learned from coding a secure online solution.

For instance, if you sign up for an online service and expect your login details to arrive via email within the next few minutes, your data cannot be secure, because the encryption key must be somewhere under the door mat. This is fine for demonstration purposes, and I use it myself for the secure booking service demo, but it's not good enough for the real thing, where customers rightly expect their information to be protected.

An online service cannot be secure when signing up is a matter of seconds. In fact, the setup of a secure online service requires manual work (of a human) on a server and of course some communication between the interested customer and the responsible person at the online service provider. The reason is simple, if the encryption key cannot be hidden under the door mat, it must be entered into the system from the outside in the moment when the encrypted information is needed. Using the system in a secure way requires preparation that cannot entirely be automated or, let me say, should not be automated at all, if you don't wish to encounter unpleasant surprises along the way.

What about lost passwords ?

Storing passwords in a database with the key under the door mat, no! Once the system is secure the database can only be re-encrypted with a key coming from outside the system. If you think the secure server should be able to reset your account easily, you're wrong. This would only be possible with a second emergency key stored on the server under a second door mat. No, the solution is to contact the service provider and make him use his emergency key which is safely stored outside the system to re-encrypt the database. That means, you'll have to wait until a human being does something useful for you. Is that too much of an inconvenience? I don't think so. Don't expect a server to do it instead. Get rid of this belief.

And if that takes time and costs money, be happy that your problem is being taken care of securely. And stop searching for a dirt-cheap, automatic way to have your negligence corrected without having to talk to a real human being.

]]> The New Java Plugin for Firefox 4 tag:linuxcoaching.ie,2011:/linux_coaching//1.32 2011-04-05T18:19:29Z 2011-04-10T20:33:27Z Maybe you've tried to get the new firefox 4 to display applets by using the good ol' libjavaplugin_oji.so with no success. It took me a while to discover that newer versions of firefox require a different plugin called libnpjp2.so which... Ralph http://kerry-linux.ie libjavaplugin_oji.so with no success. It took me a while to discover that newer versions of firefox require a different plugin called libnpjp2.so which is located in a totally different place in Sun's JRE tree.

Create a symbolic link in your plugins directory (either /usr/lib/mozilla/plugins or in your home directory in $HOME/.mozilla/plugins) and your firefox 4 should be able to display applets.

ln -s /usr/java/jre1.6.0_24/lib/i386/libnpjp2.so /usr/lib/mozilla/plugins

Why did nobody tell me?

]]> Locking Spammers Out Of Your Mailserver tag:linuxcoaching.ie,2010:/linux_coaching//1.31 2010-12-10T12:08:22Z 2010-12-10T12:09:23Z It's amazing what you can do with SSL certificates. In an earlier posting I showed you how to secure your email access by using SSL certificates. To achieve this, we had fortified our mail server to always establish pure... Ralph http://kerry-linux.ie how to secure your email access by using SSL certificates. To achieve this, we had fortified our mail server to always establish pure SSL secured connections for the retrieval of an users' email. We did that to stop network snooping folks to read email passwords in transit and to make sure that someone who got to know a user's password would even need another secret information (the user's SSL secret key) to get at the mailbox content.

Now we will use the certificates we needed to fortify our IMAP server to make the other half of the mail system, the SMTP server, secure too. The SMTP servers today are used to accept email messages that are bound for a certain destination for which the server is authorative. But to deny spammers the chance to indulge in their nefarious activities SMTP servers usually refuse to relay email messages to other servers under normal circumstances. There's nothing wrong with it as long as the machine that is used to send the email has a public IP address that was never used to send spam before.

But once you've tried to send email via a dial-up connection or a public wireless access point, chances are that your dial-up IP address is marked as a dubious source and you cannot send your email because you are blocked by some intelligent software that pretend to know your're a spammer. There is no point in arguing, your only chance is to send your email into the internet via a "clean" relay host, with a static IP address, that is able to make a difference between you and all the spammers that pretend to be you.

In essence, we have to find a way to authenticate ourselves to the clean SMTP server in a secure way. Obviously, all the system users that are listed in the mail server's user database should be allowed to use the server as a mail relay host. But then, they have to submit their passwords to the mail server to authenticate and, as you probably would have known by now, this should only be permitted through a secure link using SSL or TLS.

Switching On Authentication

Most people sending email don't think about having to prove their identities to a mail server, they expect to be able to send email the same way as they are used to stuff anything into a real letter box. From the perspective of the mail server, a correct username password pair is the only thing that differentiates a valid user from the spammers. That's why it is important to educate people, that giving a password is not too much of an annoyance for the benefit of sending email while on the move. Anyway, once we have set up the system to use SSL certificates with an outgoing mail server, users will not see much of a difference except that they have to provide their password when sending the email out.

Adding A Secure Tunnel To SMTP

As the mail server is our main secure entry point for email into the internet our main objective is not to hide our message but to convince the mail server that we are the good guys that are allowed to inject email into the system.

SASL, the Simple Authentication and Security Layer, is being used to enable our mail server software to perform the necessary authentication checks. But before we can enable the use of SASL inside postfix, we have to start a deamon, the saslauthd

chkconfig saslauthd on
/etc/init.d/saslauthd start

The following code is used to enable sasl in postfix and has to be added to the main postfix configuration file:

# SASL support for authentication
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination

# TLS support for postfix
smtpd_use_tls = yes
smtpd_tls_auth_only = yes
smtpd_tls_key_file = /etc/postfix/mailserver.key
smtpd_tls_cert_file = /etc/postfix/mailserver.cert
smtpd_tls_CAfile = /etc/postfix/CA.cert
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom

The last few lines of code will tell postfix to use TLS (the replacement for the older SSL mechanism) and the location where to find the mail server certificate and key as well as the CA file to verify the trust chain.

With these modifications of the server side, we have essentially locked out everyone from using our mail server who is unable to provide the correct username and password over the TLS connection to our mail server.

Don't Forget Your Client!

The first thing we'll notice when we send our next email is that it won't go out as our email software used to ignore TLS so far for outgoing mail. To be able to send email out again you have to change your settings in the "SMTP" section of you email client software. After selecting TLS encryption and providing the username for the mail server you should be back on track again. In my case I had to upgrade my email software to ALPINE 2.0 to get busy, because my old software (pine) didn't know a thing about TLS. But that could only happen to me as I tend to stick to the old reliable programs when the rest of the world has already moved on to the cutting edge solutions.

]]> Going SSL With Evolution tag:linuxcoaching.ie,2010:/linux_coaching//1.30 2010-03-27T18:39:59Z 2010-12-09T16:11:03Z You may have followed my advice I gave in an earlier posting to set up a secure email server that will allow clients to fetch their email from the server only if they present a valid SSL certificate in addition... Ralph http://kerry-linux.ie my advice I gave in an earlier posting to set up a secure email server that will allow clients to fetch their email from the server only if they present a valid SSL certificate in addition to the usual password for the mailbox user. The most appealing aspect of this approach is that once the system had been set up, the client user, who has already stored his certificate on his local laptop will just have to provide the password as usual. This solution comes with no additional burden, and at the same time ensures that the email travels encrypted from the email server to the laptop. A clear boost of security, fine.

The only problem is that the email client software must be capable of establishing a SSL connection using the users certificate. Unfortunately not every prominent email software is able to do that. In my case I fetch my email from the server with fetchmail as I'm interested to archive all incoming email.
But email software usually tends to fetch the email on its own account. So the lack of being able to establish a SSL connection could clearly ruin the new approach.

What's Written On The Tin?

As a consequence I was very surprised to learn that Evolution, generally being celebrated as the Outlook killer software, actually is one of those culprits. Googling towards a solution I came across some well-intended advice "just" to upload the my certificate using the pertinent buttons in Evolution. This is good advice although it requires a little bit of openssl hacking to beat the two separate cert and key files in shape to form a p12 file, but it doesn't solve the problem at all. Evolution uses uploaded certificates to sign messages a user sends to other people, but it still refuses to use such a certificate to establish a SSL connection to the mail server. Strange, but true.


Let The Expert Do The Connecting

Fortunately there is a small but powerful piece of software that is rapidly becoming my favorite tool in such situations, called STUNNEL. Its primary goal is to read data from one port and to connect to an entirely different port on a different computer, initiating a clean SSL connection with the certs and key provided in a single configuration file. From the remote server's perspective it looks like some SSL capable software had connected to the server, while indeed any dumb non-SSL-aware code is using stunnel to do the hard work. This code could as well be Evolution, right? Let's have a look at the simple config file for stunnel:

debug = 7
output = /secure/stunnel/logfile
pid = /secure/stunnel/stunnel.pid

[imaps]
accept = laptop.kerrylinux.ie:143
connect = mail.kerrylinux.ie:993
CAfile = /etc/pki/tls/cert.pem
cert = /secure/stunnel/joe@kerrylinux.ie.cert
key = /secure/stunnel/joe@kerrylinux.ie.key
CRLfile = /secure/stunnel/CRL.pem
client = yes

Essentially, the "normal" IMAP port 143 on the laptop is wired as a secure IMAPS mail server to be used by Evolution. All certs and keys are stored in a secure place on the laptop.

Getting Evolution To Use The Tunnel

The remote mail server mail.kerrylinux.ie would usually be listed as the server in the settings for "Receiving Email". Now you just have to replace this entry with the local laptop's name and make sure that "no encryption" is selected. Remember it is STUNNEL's job to perform the SSL encryption not Evolution's. "Yes, but it should be evolution's", I can hear you say. You're right, but even if the evolution team decides to sex up their software in future, this solution will work for every other non-SSL capable email client as well, and that's the reason why I told you how to do it.]]> Tracking Down A Suspected "Backdoor" tag:linuxcoaching.ie,2010:/linux_coaching//1.29 2010-01-29T08:08:49Z 2010-02-11T06:40:16Z After having installed an open source online-shop software on a VPS I had to suffer a hefty delay following the login as administrator until eventually the control panel appeared on the screen. Despite of this admin login problem the software... Ralph http://kerry-linux.ie
img13.jpg    Possible causes for this problem are manifold, some misplaced configuration option, a software bug, a missing software component, many things are conceivable.

What raised my suspicion was the fact that this problem seems to occur only at the administrator login, well, I hadn't created new users by now.


It is likely that the problem occurs for new users as well.

The Hunt

Actually there were two separate delays that cropped up after I typed the admin password, with a little bit of activity in between. It looked like a time-out, so I shut down the VPN's firewall and the problem was gone. At this point it was clear that some network activity took place which normally was blocked by the firewall. To find out what was going on I engaged a wonderful network analysing tool called wireshark or tshark to capture the network packets after login. It turned out that the VPN initiated a http and a second https connection to a server within the domain of the online-shop's original vendor.

I know it's only me who tends to think of a possible backdoor, a software "calling home" to report something, in such a case. But at this point I wanted to find out what was going on behind the scenes. Out of sheer curiosity I started to poke into the source code to find more informative evidence. As you may imagine, looking for "http" in the source code revealed tons of references that were mostly inactive links to the vendor's homepage. More extensive filtering brought a function "load_xml_file" to light that was used to download a file that contained only innocent version information in XML format that could as well be part of the distribution and stored locally.

Benefits of Open Source

The vendor had decided to download this file to make sure that the online-shop software will automatically become aware of a new version once it is released. Of course this is a legitimate intention, but it would force the shop user to open outgoing connections on the server machine to avoid the timeout penalty which could open up another can of worms for other applications. I decided to change the source code to load the information from local files instead of the vendor's homepage and turned on my restrictive firewall again.

This is exactly the flexibility and reliability one gets with using open source software which would never, ever be possible if you used proprietary solutions instead. People often say, nobody looks at the source code, which is true for many open source programs, but with proprietary products you would not even have the chance to take the approach described above, because you are at the vendor's mercy to accept what the program is actually doing.

The freedom to change the code is a benefit that could possibly not be overestimated.

]]> Celebrating Expiration Day tag:linuxcoaching.ie,2010:/linux_coaching//1.25 2010-01-02T16:53:16Z 2010-01-24T21:31:50Z On the last day of the year my email stopped coming in. You may have read about my approach to fetch my email using a secure tunnel that uses SSL certificates in addition to a password to access my email.... Ralph http://kerry-linux.ie my approach to fetch my email using a secure tunnel that uses SSL certificates in addition to a password to access my email. Well, on the last day of the year my ROOT CERTIFICATE, which I use for Kerry Linux, had expired after five years. Time flies by.

As I had other plans for the days ahead I thought just to renew the root certificate to buy time, but it seemed that my attempts to renew my root certificate did not result in a new usable certificate to replace the old one. My user certs, which are not up for expiration yet could not be reanimated with a quick fix like that.

After a while I thought, there is a reason for that and I began to think about root certificates more thoroughly. In the past five years we've definitively seen the crackdown of MD5 and SHA-1 is not invincible, too. Would it not be prudent to increase the key length and to use a more secure (i.e longer) hash and go through the trouble of creating a new root key and issue new user certs? I decided to go along that route and created a fresh new CA root key with 4096 bits for the Kerry Linux Certification Center. Although my openssl software does only permit using SHA-1, which is a pity, I felt content and everything was up and running for me in an hour or so.


Re-Animation of the old ROOT KEY

After a while I began to wonder if it was possible to reanimate the old key and out of curiosity tried to explore the way to do it in more detail. I googled and found this nice posting from Arsen Hayrapetyan which led me to success. My former attempts to recreate the old certificate always led me to the following error message when I tried to verify a user's certificate::

openssl verify -verbose -CAfile KLCC-2010.pem support@kerrylinux.ie.cert
support@kerrylinux.ie.cert:
/C=IE/ST=Ireland/L=Kerry/O=Kerry Linux/CN=support@kerrylinux.ie/emailAddress=support@kerrylinux.ie
error 20 at 0 depth lookup:unable to get local issuer certificate

Unable to get the issuer certificate? I supplied it in the command, but it didn't work out as planned.

So I followed Arsen's hints and created a testbed for an experiment, where I set the serial number back to 00 and emptied the file "index.txt" so that my new certificate could inherit the properties of the old one including its serial number. Then I created a new certificate request based on the old root certificate "cacert.cert" and used this new request to sign it with the old key.

openssl x509 -x509toreq -in cacert.cert -signkey private/cakey.pem \
-out certreq.csr

openssl ca -config KLCC.cnf -in certreq.csr -out cacert_renewed.pem \
-keyfile private/cakey.pem -cert cacert.cert -extensions v3_ca


The result was a new root certificate "cacert_renewed.pem" that verified my old user certs perfectly.

openssl verify -verbose -CAfile cacert_renewed.pem \
support@kerrylinux.ie.cert
support@kerrylinux.ie.cert: OK


It's good to have an alternative, isn't it?

]]> Using Big Files As Hard Disks tag:linuxcoaching.eu,2009:/linux_coaching//1.24 2009-12-01T06:34:10Z 2009-12-01T06:04:31Z The XEN hypervisor uses big files (a couple of gigabytes) as filesystem images for virtual machines. Unlike other virtualisation solutions XEN does not impose its own internal structure on the image file. The big file simply has to contain... Ralph http://kerry-linux.ie
  1. Provide the VM's kernel and the init-ramdisk, which are usually stored inside the filesystem (in the /boot directory), as separate files together with the big file, and modify the VM's configuration to use them.

  2. leave the kernel and the init-ramdisk in the big file and provide a working boot sector that accesses the kernel inside the big file, using the native XEN pygrub bootloader to start the virtual machine.
Both options require that the big file must be associated with a real, special device file (i.e /dev/loop0) in order to create a filesystem on the big file. While for the first option it is sufficient to simply connect the big file with the loop device, using the "losetup /dev/loop0 bigfile" command, the second option is much more complex, as the big file has to be partitioned like an ordinary hard disk before the filesystem can be created.

For the rest of this article we will focus on the second option which is much more appealing as everything is kept inside the big file. I will show you how exactly the big file is turned into a virtual hard disk and how you can access and modify the information stored in the virtual machine's own filesystem.

Getting Partitions And Filesystem Sizes Sorted

Our journey through the big file's internal structure naturally begins with the creation of the big file.

dd if=/dev/zero of=bigfile bs=1M count=3950

As a second step we use this chunk of 4141875200 bytes to act as a hard disk and try to partition the bigfile as usual:


losetup /dev/loop0 bigfile
fdisk /dev/loop0

Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel. Changes will remain in memory only,
until you decide to write them. After that, of course, the previous
content won't be recoverable.

Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

Command (m for help):

As expected, the fdisk program throws a number of error messages at us, because we have given a big file instead of a real hard disk to the program. But let's see how the fdisk program recognizes our new hard disk in detail
.
Disk /dev/loop0: 4141 MB, 4141875200 bytes
255 heads, 63 sectors/track, 503 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System

Obviously there is no partition table yet, but the program assumes that the big file represents a hard disk with 255 heads and 63 sectors of 512 bytes data each. Every cylinder of our virtual hard disk is made of 255 x 63 x 512 bytes = 8225280 bytes which represents the units in which we can chop the hard disk space into partitions now. All in all there are 503 cylinders in our virtual hard disk which makes a total of 503 x 8225280 bytes = 4137315840 bytes to spend on partitions.

But wait, didn't we create 4141875200 bytes in the first place? That's 4559360 bytes less than what we had originally. Well, this loss is due to the fact that for the 504th cylinder we'd need 8225280 bytes which we don't have, so this loss is inevitable. But the important consequence of this reduction of space is that we cannot create a filesystem on the whole bunch of data we supplied. At the moment the size of our filesystem is not determined at all. The next step is to create a new primary partition inside our big file using all the space we have:

Disk /dev/loop0: 4141 MB, 4141875200 bytes
255 heads, 63 sectors/track, 503 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System /dev/loop0p1 1 503 4040316 83 Linux

After having written the partition table to the big file, have you checked for the new device file /dev/loop0p1? Don't worry, it does not exist! Adding p1 to the disk label is fdisk's way to denote partitions, that does not mean that you'll find such a thing in the /dev directory.

Poking Inside The Big File

From the partition table you can see that 4040316 blocks have been allocated for the new partition. With each block storing 1024 bytes we now know our first partition size, it's 4040316 x 1024 bytes = 4137283584 bytes. This is another number we never saw before! After having written off some 4.5 megabytes because we cannot use half a cylinder, we now face another loss of exactly 4137315840 - 4137283584 = 32256 bytes.

Of course these 32256 bytes at the beginning of the big file are there for a purpose, which is to store the partition table. Our first partition begins right after this amount of data, at an offset of 32256 inside the big file. The amount of 32256 bytes results from the fact that one track (63 sectors of 512 bytes for one head) are put away for the partition table. Now it's time to use a second loop device (/dev/loop1) to poke inside the big file at exactly the point where our first partition begins and create a new filesystem there:

losetup -o 32256 /dev/loop1 bigfile
mkfs -t ext3 -c /dev/loop1 4040316

It's essential that we supply the number of blocks as a parameter to the mkfs command to ensure, that our new filesystem on the first partition fits exactly in the space we have allocated. Without this parameter our filesystem would become too big, as the 4.5 megabytes after the first partition would be used for the filesystem too, and when the virtual machine is going to use the filesystem its actual size would conflict with the numbers in the partition table. Either the partition table or the filesystem's superblock is lying, which will cause distress for the virtual machine that expects a consistent filesystem to operate.

Writing The Master Boot Record

You can fill up the filesystem with whatever carefully selected quality open source software you can find on the planet, but in the end we need to write the new virtual disk's master boot record to boot the jewel. There is one step of preparation to be done before we can use the grub shell to write the MBR. We have to make a symbolic link named /dev/loop to the device that points to the master boot record, that is to the beginning of the big file, /dev/loop0 in the example above.

grub> device (hd0) /dev/loop
grub> root (hd0,0)
grub> setup (hd0)
grub> quit

Now your spick-and-span virtual hard disk is ready to boot.
]]> Fetch Your Email Through A Secure Tunnel tag:linuxcoaching.eu,2009:/linux_coaching//1.23 2009-11-09T11:04:26Z 2009-11-09T11:13:24Z Current Phishing Attacks In early October when news came up that quite a lot of Hotmail and Gmail accounts had been compromised by phishers who tricked users into using a faked login page the general advice for scared users... Ralph http://kerry-linux.ie Current Phishing Attacks In early October when news came up that quite a lot of Hotmail and Gmail accounts had been compromised by phishers who tricked users into using a faked login page the general advice for scared users was: "change your email password immediately". Although nobody really knew how the email passwords published on the internet were gathered, it became common knowledge that only those users who had used the phishing sites to log into their email accounts were vulnerable. Everybody else whose account was not blocked by the email providers started to feel safe again.

The fundamental problem with email is that access to the mail account is only protected by a password, and that every time a user fetches his email from the internet service provider (ISP), his password is transmitted to the mail server in clear text. To improve the situation email service providers are beginning to use opportunistic TLS, a method to encrypt traffic between mail servers. In this cases encryption is used if the mail server provides it, and in a perfect world mail would always travel encrypted to the user's mail server. But opportunistic TLS does not solve the user's problem as almost all email software he actually uses do rely on a password only to access an email account.

The Perfect Mail Server

In fact, what we have to do is to make sure that email is properly encrypted while the user fetches it from his email account, and that the mail server establishes a connection only if the person trying to get the mail is able to present more information than a password. This configuration would not only protect the email content and the password during transmission, it would as well ensure that someone only knowing the password would never be able to establish a connection to the mail server.

Fortunately this can be achieved without an additional burden on the user, because we only need a careful setup on the server side and provide the user with the additional information (a secret key) which has to be stored safely on the computer that initiates the mail transfer for her.

Setting Up A Secured Mail Domain

Let's start with the mail server configuration, which in my case is dovecot 1.0.7 on a CentOS server. I will show you how to configure dovecot to provide the mailbox of system users in a secure way. I assume that the firewall on the mail server is open for incoming mail on port 25 and that the mail server uses port 993 for outgoing secure IMAP traffic.

This is the essential part of the "dovecot.conf" file I use for secure IMAP access:
(I discuss the relevant parts of the configuration only)

protocols = imaps pop3s
listen = [::]

ssl_disable = no
verbose_ssl = yes

ssl_cert_file = /kx/dovecot/mail.kerrylinux.ie.cert
ssl_key_file = /kx/dovecot/mail.kerrylinux.ie.key
ssl_ca_file = /kx/dovecot/kxCAcrl-bundle
ssl_verify_client_cert = yes

mail_location = mbox:~/mail:INBOX=/var/spool/mail/%n

auth default {
  mechanisms = plain
  passdb passwd-file {
      args = /kx/dovecot/%d/imap.shadow
  }
  userdb passwd-file {
      args = /kx/dovecot/%d/imap.passwd
  }
  ssl_require_client_cert = yes
}


First of all, by restricting the protocols to imaps and pop3s dovecot releases port 143 and 110 which could safely be blocked now. There are three certificate files which have to be in pem format. While the first file contains the public certificate for the mail server, the second must hold the unencrypted secret key. The file permissions on the later have to be restricted to read access for the root user as the key is read by the dovecot process before dropping permissions to the dovecot user.

The third file does not only contain the RootCA's certificate but also a valid Certificate Revocation List in pem format appended to the RootCA certificate with a newline in between. Without the CRL in this file the user's certificate cannot be validated and the connection will not be established. It is extremely important to keep an eye on this CRL, as the time frame for replacing a CRL is usually only a few days long. If you miss to keep the CRL part up-to-date you'll risk that the perfect mail server setup expires in a few days, leaving your users with no access to their email. You can create long-living CRLs with the openssl crl command as you like, but bear in mind that the expiration date of your CRL does determine the ability of your users to get at their mail in the same way as does the expiration date of the user's certificate.

You may have noticed that in the authentication section everything is disabled except the use of two files which serve as a static user and password database. Only system users listed here are able to access their mailboxes. The two files "imap.passwd" and "imap.shadow" are exact copies of their system analogies, limited to the lines of valid email users. Just make sure that both are stored in a directory with the name of the email domain you use, which is shown as %d in the configuration file above.

Finally, the last line "ssl_require_client_cert = yes" determines that the mail server shuts down the connection if the user's email client is unable to present a client certificate, that the mail server can validate based on the content of the CA certificate file in the configuration.

By now we have made access to our mailboxes as difficult as possible, it's time to make it accessible for the user in a way that does not hurt. Please read on.

Supplementing The Mail Password With SSL Certificates

What the user needs is a certificate, a public key, which is signed by the RootCA used by the mail server and a corresponding secret key. And, of course, a software that uses this information to download the email from the user's mailbox to the local machine over an encrypted tunnel. With another careful setup on the client's computer this is automatically done by the fetchmail process that can be run via cron in certain intervals. So the users receive their mail without bothering about the encryption process at all. They can read their internet email just like they read their local email.

Fetchmail uses a config file ".fetchmailrc" which has to be protected carefully (read access for the root user only) as it contains all the user's email passwords. It looks like this:

poll mail.kerrylinux.ie protocol POP3

  user joe@kerrylinux.ie password PASXXXXXX is joe here
     ssl sslcertck sslcert /secure/certs/joe@kerrylinux.ie.cert
     sslkey /secure/certs/joe@kerrylinux.ie.key

  user patrick@kerrylinux.ie password PASXXXXXX2 is paddy here
     ssl sslcertck sslcert /secure/certs/patrick@kerrylinux.ie.cert
     sslkey /secure/certs/patrick@kerrylinux.ie.key

For the client to establish the SSL connection it is not enough to present the public certificate to the mail server, it is also necessary to be able to use the secret key. And this is what the attacker who may have learned the email password will not posses and what will keep him out of our mailboxes.

If you have trouble creating those certificates, please drop me an email and I will see what I can do for you.

]]> WEP Is Dead, Long Live WPA tag:linuxcoaching.eu,2009:/linux_coaching//1.22 2009-09-28T17:54:23Z 2009-09-28T17:55:47Z The Final Nail in WEP's Coffin I have to admit it, this is old news, very old news. WEP is dead, and the final nail had been driven into WEP's coffin some three years ago. But many WiFi networks... Ralph http://kerry-linux.ie The Final Nail in WEP's Coffin I have to admit it, this is old news, very old news. WEP is dead, and the final nail had been driven into WEP's coffin some three years ago. But many WiFi networks still use WEP today, although a much more secure alternative, WPA-2, has been available for a long time.

People tend to believe that any encryption is better than none and don't bother to use high-grade security methods instead of broken ones like WEP. Obviously the publication of research papers does have a limited effect on the ordinary user's willingness to change habits or consciousness of the problem. Unless the weak methods disappear from the router's firmware menu, we'll see people using it.

Switching Over to WPA

It's fairly easy to dump WEP and to use WPA-2 instead, because WPA-2 can use a pre-shared key, a secret that must be available both in the router or access point and in the client machine that is about to establish a secure wireless connection. There is clearly no need to add further complexity (like Radius servers and the like) just to replace WEP for a simple wireless link.

In a first step you have to change the security settings of the access point / router to WPA2-PSK and select a new long secret key for encryption. As WEP-2 uses the advanced encryption standard (AES) with a 256 bit key, the new secret key ought to have as much entropy as possible. You can use the following command to get a reasonably long random secret (of 160 bit entropy) for use by the router and the client.

#> dd if=/dev/random bs=1 count=200 | sha1sum

After that your wireless client is cut off, as the router makes use of a different, and more secure, access method. It's prudent to use a new secret key as your encryption has been weak in the past and the old one might have been compromised long ago, you'll never know for sure.

In order to re-establish the wireless link the client machine will use a daemon software called wpa_supplicant that has to be started just before the wireless network adapter starts to reach out for the access point or router. Of course the wpa_supplicant will need at least two pieces of information, the name of the wireless network (its SSID) and the secret encryption key, we've already stored in the router. Please double-check that the daemon's config file has minimal permissions (root read access only) to protect the wireless secret key and add something like the following lines to your config file "/etc/wpa_supplicant/wpa_supplicant.conf":

network={
ssid="your-wireless-network-name"
scan_ssid=0
key_mgmt=WPA-PSK
psk="420320d9c0fa8e6cc635381f4717090224385965"
}

The only thing you need to ensure is, that the daemon is started whenever you use your wireless adapter, and that the firewall recognizes your new link. Yes, it's that easy to dump WEP for good. Finally. ]]> Booting a CD Without a CD Drive tag:linuxcoaching.eu,2009:/linux_coaching//1.21 2009-08-31T07:04:47Z 2009-08-31T07:06:48Z ISO Files Most Linux distributions and a number of CD utilities like Clonezilla or GPARTED-Live come as iso-images, ready to be burned to a CD medium, to start an installation or running a live session for some useful purpose. But... Ralph http://kerry-linux.ie ISO Files Most Linux distributions and a number of CD utilities like Clonezilla or GPARTED-Live come as iso-images, ready to be burned to a CD medium, to start an installation or running a live session for some useful purpose. But all these iso files are supposed to be booted inside an ordinary CD drive. What if you just don't have a CD burner at hand or if your CD drive is damaged or missing all together, because you are testing the shiny new motherboard without a CD drive?

Don't think you are stuck, there's help around the corner that will lead you into a habit of booting your iso files in a much more creative fashion.

"Stop for a moment, could I not simply put the iso file on a USB key using the dd command? Most modern BIOSes are perfectly capable of booting USB keys and surely there is a USB slot on your new motherboard you can use."
Of course you could do that, the iso file contains a valid iso9660 filesystem together with the bootloader for CDs. And the dd command will transfer the file to your USB key without adding any other structure. But, don't expect the new USB key to boot like a CD, because after you have changed your BIOS settings to allow booting from a USB hard disk, the BISO will expect the structure of a hard disk not that of an iso-filesystem. It will look for a MasterBootRecord (MBR) in sector 0 in the same way as if it would boot your ordinary hard disk. And an iso-filesystem doesn't have a MBR and a partition table where the BIOS expects it to be. So forget booting iso files directly.

"Ok, seems as if there is no way around putting a bootloader like grub on the USB key, and ... , wait, there is a file called iso9660_stage1_5 in the grub directory. It looks like grub has iso9660 support already. Can we use this to boot the iso file?"
Well, unfortunately no. The iso9660 support built into grub can be used to create a bootable CD with grub as the bootloader. Your file is being used when a new iso file containing your grub bootloader is created. What we need instead is the ability to read the kernel and the initramdisk inside the iso-filesystem at boot time when no filesystem is mounted.

"Sounds as if we need a loop device to get at the files inside the iso filesystem. Does grub support mounting a iso-filesystem using a loop device?"

The New Grub

Yes and no. The traditional grub (version 1) that everyone uses does not have this loopback support, but the grub development team has been working on grub2 for a number of years now, which has loopback support already. The new grub2 is still under development, so it's not yet ready to replace the legacy grub version 1, but grub2 is exactly what we need to boot our iso files directly.

A Word Of Caution

So we are about to prepare a USB key to boot iso files with the grub2 bootloader written into the key's master boot record. Writing MBRs on a Linux system usually raises blood pressure a bit, as we have to be extra cautious not to ruin our running Linux system. If you want to follow me from here, please make sure that you do not perform the grub2 installation on your company's production server and double-check everything before issuing commands, to be on the safe side. And for those of you, who hesitate to write MBRs at all, I have an offer for you at the end of this posting, read on.

Preparing The USB Boot Key

Like any other software grub2 can be installed using the distros repositories, at least with Fedora 11 that I use now. The installation will not replace our legacy grub software we are using to boot our computer, as the new files go into a directory "/boot/grub2" without changing anything of the current grub setup unless grub2 is deliberately used to overwrite the MBR. And this is the only thing we have to avoid. But for now, our objective is to get the grub2 software onto our USB key, writing the key's MBR will then be the crowning event before we start testing the key.

For preparing the boot key it is absolutely essential that you know how the Linux kernel recognizes your USB key. To find out, you can observe the log file "/var/log/messages" while you plug your key into the computer. For now I assume that you have one hard disk in your computer (/dev/sda) and your USB key will probably show up as /dev/sdb. First we re-partition the key and create two Linux partitions, a small one of 10 MBytes for the grub2 software and a larger one where all our iso files can be stored:

#> umount /dev/sdb1
#> fdisk /dev/sdb
#> mkfs -t ext3 -c /dev/sdb1 ; tune2fs -L usbboot /dev/sdb1
#> mkfs -t ext3 -c /dev/sdb2 ; tune2fs -L isos /dev/sdb2

You can now mount the second partition and copy all the iso files you wish to boot into this location. Writing the MBR now requires that the first partition is mounted on a well know mount point like /mnt, because we will use this directory to write the grub2 software to the key with the following command:

#> grub2-install --root-directory=/mnt /dev/sdb

Please double-check that your key is mounted and is called /dev/sdb before you use this command, which populates the directory /mnt/boot/grub2 with grub2 modules and writes the MBR into /dev/sdb.

As you may know there is one task still left before we can start testing our boot key, we need to create a menu list, which is called "/boot/grub2/grub.cfg" now. A number of changes have been made to the config file compared to the old grub, so let's have a look at the new configuration:

set timeout=5
set default=0

menuentry "ISOLINUX" {
loopback loop (hd0,2)/centos.iso
set root=(loop)
linux /isolinux/vmlinuz
initrd /isolinux/initrd.img
}

The most remarkable change is the numbering of partitions which has become more natural as the first partition now is (hd0,1), while hard disks still start with number 0. Then the old title entry is replaced by menuentry and loading the kernel is now done with the linux command. Apart from all these cosmetics we can now create a new device called (loop) that will replace a real partition like (hd0,2) to access files inside the iso-filesystem, once we have connected the iso file with this new device using the loopback command.

It is even possible to list the files that grub2 can see on the (loop) device using the grub2 command line:

grub2> set root (loop)
grub2> ls /

Now it's time to check if the ISOLINUX menuentry works. Reboot and see your new boot key fire up the CentOS netinstall process. Voila.

Download Your Bootable USB Key

I have prepared an image of my boot key for you that you can download, if you want to create a boot key without the hassle of following the steps above. The small 32 MByte image file contains all the magic and can be copied to your USB key with the dd command. Please send me an email and I will give you a download link with the necessary instructions. Once you have your key working, you can delete and re-create the second partition to make space for all your live CD iso files on the key. All you need to edit is the config file.

That way you can carry all your distros on one key and boot them all from the grub2 menu without having to change the Linux system on your hard disk. ]]> Hardcore Virtualisation - Learn To Love XEN tag:linuxcoaching.eu,2009:/kerry_linux_help_center//1.16 2009-08-17T08:29:20Z 2009-08-17T08:44:29Z A few weeks ago I happened to install CentOS-5.3 on a HP blade server, and while scrolling through the software selection dialog, I ticked everything that had to do with Virtualisation and Clustering. Consequently, the new system came up... Ralph http://kerry-linux.ie
Everything else was still pretty normal, but the XEN kernel was constantly reminding me to use it for what it's for, starting a virtual machine. As you may know Xen is not the easiest way to get such a virtual system in place even thought there is a graphical frontend for Xen as well. But there is one advantage of Xen that makes up for all the trouble you are having to get the thing going and that is speed.

Unlike other virtualisation software like VirtualBox that are designed to run unmodified operating systems within an application environment that emulates everything, Xen aims at running on bare hardware as directly as possible. Xen promises to achieve near native performance by putting a kernel software called hypervisor between the hardware and the guest operating system. The hypervisor occupies the privileged part of the CPU driving the guests away into the non-privileged areas of the CPU, but offering to execute privileged code on behalf of the guests whenever they need to use privileged code. It is this design, that speeds up performance but on the other hand makes it necessary that the guests find their way to the hypervisor by using a special Xen-enabled kernel themselves. So operating systems that cannot be modified to have a Xen kernel (like Microsoft Windows) cannot run in the speedy paravirtualized mode.
 

Beware Of Using Defaults

In my experience, what makes Xen very tricky to use at first, is that the default values after a fresh installation can easily break your network connection, leaving you with plenty new network interfaces but without a working local network, let alone the internet. On boot there are two services that are being started for the Xen system, the libvirtd and the xend daemons. These services read a single, very short  configuration file "/etc/xen/xend-config.sxp" which consists of only nine lines:

(xend-unix-server yes)
(xend-unix-path /var/lib/xend/xend-socket)
(xend-relocation-hosts-allow '^localhost$ ^localhost\\.localdomain$')
(network-script network-bridge)
(vif-script vif-bridge)
(dom0-min-mem 1024)
(dom0-cpus 0)
(vnc-listen '0.0.0.0')
(vncpasswd '')

And line no. 4 is the culprit that renames a working ethernet interface, recreates it and introduces two bridge interfaces leaving a mess in which nothing does work any more. I strongly suspect that this is not what defaults are for. Fortunately a small modification gets Xen on track again. Simply don't use the script "network-bridge" and replace it by /bin/true, problem solved. It seems to me that the Xen defaults are striving to isolate the new virtual machines from the ethernet as much as possible, while someone starting to use Xen might want the virtual machine to use the already working internet adapter with a new fixed IP address in the LAN.

Use Your Own Bridge

If you are after a new virtual machine on the same LAN you can create a config file for a bridge (br0) that replaces your ethernet interface and connect your ethernet interface to that bridge. All firewall settings for your host can remain the same as your new bridge takes over the old fixed IP address and nothing seems to have changed for the LAN. Once your virtual machine is ready to run, just use the new bridge br0 as network interface in the config file and you can assign an unused IP for the guest on the LAN with the default gateway for internet access, and everything works well.


/etc/xen/xend-config.sxp

...
vif = [ "mac=00:16:3e:27:84:7a,bridge=br0" ]


/etc/sysconfig/network-scripts/ifcfg-br0

DEVICE=br0
TYPE=Bridge
BOOTPROTO=none
ONBOOT=yes
DELAY=0
IPADDR=192.168.2.188 # your host's LAN IP may be different
NETMASK=255.255.255.0
GATEWAY=192.168.2.1 # adapt IP here


/etc/sysconfig/network-scripts/ifcfg-eth0

DEVICE=eth1
TYPE=Ethernet
BOOTPROTO=none
ONBOOT=yes
BRIDGE=br0
GATEWAY=192.168.2.1


Try it, and you are beginning to love Xen!

]]> Just Linux Everywhere tag:linuxcoaching.eu,2009:/kerry_linux_help_center//1.14 2009-07-18T09:21:42Z 2009-12-23T15:45:14Z Ralph http://kerry-linux.ie
img4.jpg    Just Linux Everywhere is a virtual machine that you can run on almost every operating system including Windows XP/Vista, Mac OS-X and of course Linux itself. As it is based on Sun Microsystem's VirtualBox Software you will be able to run a fully fledged Linux inside a window just like another application inside Windows or Mac OS-X. No fundamental changes like overwriting the Master Boot Record are being made to your hard disk to run Linux, which is entirely confined to two or three big files on your computer that come with the Kerry Linux DVDs.

Essentially there are two different versions of Just Linux Everywhere, a compact version of 4.7 gigabytes (JULIE) that contains the prominent software packages like Firefox, OpenOffice and Evolution and more, which fits on one single DVD and a lager one, JULIEplus that strives for providing all the very best of Linux software available at the moment.

Both versions are fully configured, thoroughly tested and ready to run within minutes, once you have installed the VirtualBox software in your operating system. There is simply no easier way to get Linux running on Windows and Mac without the hassle of installation and testing.

And there are more options to avail of, as JULIEplus can be set up to store 1 gigabyte (or more) of user data online on a server on the internet encrypted using an automatic backup solution. You can use this option anytime, because JULIE is prepared to use the Kerry Linux Support Server on your request to provide remote administration of your virtual machine by Kerry Linux if you like to entrust me to manage your system remotely.

These are the options that are available for you at the moment:

JULIE JULIEplus
Requirements Sun VirtualBox Sun VirtualBox
Size one DVD, 4.7 GByte two DVDs, 8 GByte
Kerry Linux
Support Option 		available available
Online Backup Option NO YES
Delivery by mail included included
Price 25 Euro 35 Euro


]]> Improve Your VirtualBox Experience tag:linuxcoaching.eu,2009:/kerry_linux_help_center//1.12 2009-06-29T18:41:50Z 2009-12-23T15:44:04Z Maybe you have followed my guide to easy virtualisation with Sun's VirtualBox software and you are familiar with the basics of running a virtual machine inside your normal Windows or Linux system by now. I hope that you enjoy... Ralph http://kerry-linux.ie followed my guide to easy virtualisation with Sun's VirtualBox software and you are familiar with the basics of running a virtual machine inside your normal Windows or Linux system by now. I hope that you enjoy the many features of your new virtual machine as most devices used by the virtual machine just work out of the box. Reading CDs and using the audio device for playback should work right away and setting up a printer via the network connection is a matter of few clicks.

But the one problem you have certainly run into by now is the low display resolution which defaults to 800x600 pixels, considerably impeding your freedom on the screen. Two simple steps will sort out this problem forever. First select a suitable "Monitor Type" in the Administration - Display dialog and save the setting. Then edit the file "/etc/X11/xorg.conf" and add something like the following in the SubSection "Display" part:

       SubSection "Display"
                Viewport   0 0
                Depth     24
                Modes "1024x768"  "800x600"
       EndSubSection

After logging out and restarting the X server again you should have a much bigger screen that almost covers the whole display if you switch into FULLSCREEN mod with <Ctl>F.

Guest Extensions pave the way for a seamless desktop experience

During the installation of VirtualBox a custom kernel module was being built that enables the host system to manage the guest, but the guest system runs without any consciousness of the fact that it is only a virtual machine. To ensure a better integration between the host and the guest, SUN have developed a package called "Guest Extensions" that must be installed inside the guest to make it VBox-aware. The installation of Guest Extensions culminate in compiling another kernel module that is being used by the guest to improve communications with the host and to make additional features like shared folders available.

Before we can use these desired features we still have to prepare the guest system to compile kernel modules, that means we have to install a full development stack inside the guest system for kernel modules first, and then install the Guest Extensions. Use the following yum command to prepare the CentOS/Fedora host:
 
yum update kernel kernel-headers kernel-devel dkms

The Guest Extensions come as an iso-file "VBoxGuestAdditions.iso" that could be found in the directory "/usr/share/virtualbox". Make sure that this iso file is available as a CD-iso-image to the guest system by adding it to the appropriate section in the Virtual Media Manager menu. Restart your virtual machine to make sure the new, updated kernel is actually running and start the setup script "VBox LinuxAdditions-x86.run" on the CD image after you have mounted the iso-file from within the guest system. After rebooting the virtual machine the new kernel module for the guest becomes active and the extensions are ready to use. The first thing you'll notice ist that the mouse pointer is no longer confined to the guest window, you can click on everything that is visible on the screen, no matter if it is a host or a guest window. And, of course, you now can copy and paste text between the host and the guest as you like it. A much more important change took place behind the curtain, your access to the hard disk is faster now. Let's have a look at the following table which gives an overview over transfer rates measured on my laptop.

Action CentOS 5.2 HOST Fedora 10 GUEST
WITH Guest Extensions 		Fedora 10 GUEST
without Guest Extensions
creating files with zeroes 27.1 MByte/sec 21.8 MByte/sec 14.1 MByte/sec
copying files 12.47 MByte/sec 11.96 MByte/sec N/A
writing to network shares 12.26 MByte/sec 5.6 MByte/sec 5.4 MByte/sec
writing to shared folders 18.0 MByte/sec 6.7 MByte/sec not available

As you can see the performance has considerably improved for writing files to disk and is almost the same for writing normal files while there is still a huge difference when network attached storage is used to extend the usually poor disk space of the virtual machine. But the use of virtual folders at least enables the host system to write data to the guest's file system rather quickly, while the guest does not really gain any speed doing the reverse operation.

Anyway, installing SUN's Guest Extension truly polishes your virtual guest machine and lets it shine brighter than before.
]]> Clone Your Hard Disk Today - With Clonezilla tag:linuxcoaching.eu,2009:/kerry_linux_help_center//1.11 2009-06-06T15:35:52Z 2009-06-06T15:37:19Z I know, you are one of those people who know that it is absolutely essential to make regular backups of your system's hard disk. There is no excuse not to make regular backups, but as we all know, we... Ralph http://kerry-linux.ie
No, you have to admit that even though the reasons to make backups are indisputable, something strange always - no, not always, but many times - keeps you from doing the necessary, updating your backups and securely storing them away. Making backups is not fun, but that's not the reason why we don't do it regularly. I suspect that you as well as I simply don't have the right tool yet, to initiate an automatic process that boils down to getting a reliable backup complete and safe to restore, which does not require much attention while assembling the data for us.

Fortunately this situation is going to change dramatically for you, today. I've run into a backup solution that is just that, an automatic process that does not require user intervention when started to do the right thing. It's called CLONECILLA and is essentially a Live Linux system, optimised for backup and recovery.

Clonezilla - Your bootable backup CD

Clonezilla can be downloaded here as an ISO-file of 106 megabytes.. This file contains everything that makes up a bootable Linux system, so be careful to write this downloaded iso-file to your CD in raw-mode. Because it's of no use to have the iso-file on a CD in another file system, the iso-file is the file system and it is the only thing that has to be on the CD.

Did I mention that Clonezilla is a backup solution that covers all sorts of partition types, so that our windows-using friends could use it, too? Clonezilla has the ability to clone a complete hard disk no matter what kind of partition your disk comprises of. It even backs up the master boot record and the partition table, you will get a complete set of data from which all or any part will be recoverable when you need it. And all data is created as zipped files of max. 2 gigabytes size so that everything can be burned to DVDs, if needed.

Setting Clonezilla on the right track

As we are now heading for a complete backup of your laptop's hard disk, one thing is to be considered before we start, where will all the backup data be stored? Fortunately Clonezilla offers a number of possible storage media ranging from an additional (plugable) local disk, a SSH server or a SAMBA server to the traditional NFS server. I assume that you have a portable USB hard disk on which you will store the backup. Please ensure that the free space on this disk is about half of the size of what you are going to backup, and add a little bit of a buffer, too.

I have found that a second thing is important before you start letting Clonezilla create the backup, make sure that all partitions of your hard disk can be mounted. Best practice would be to perform a file system check on all partitions before starting the Clonezilla boot CD.

The following few steps are all you need to initiate a full backup of your laptop's hard disk and you will see that once you've selected a few things the rest is going in a jiffy.

Step 1 Boot your Clonezilla backup CD, select language and keymap, then select "Start Clonezilla"

Step 2 After selecting the backup media (local_dev) power on your USB disk and allow a few seconds for the system to recognize your new hard disk on which the backup will be stored. Clonezilla creates a directory on the USB disk derived from the date and time of the backup. You can choose where to store this directory on the disk.

You can always switch to another terminal using <CTR><ALT>F2 to see that the USB disk is now mounted on /home/partimag. All files go into this directory.

Step 3 Select "savedisk" to ensure that the whole hard disk is backed up. When the partition information is read in Clonezilla will start the backup process automatically.

Step 4 Depending on the size of your hard disk, you can now relax and let Clonezilla compose your backup for you. Check the backup directory in the meantime to see it filling up with data.

The performance of creating the backup is very good, it took 47 minutes for a 30 gigabyte data partition on my three year old laptop. The whole disk (120 gigabyte) was ready after two and a half hours time leaving me a total of 66 gigabytes of compressed data.


Try Clonezilla today, it takes very little time to be secure. No excuses!


]]>