Why have some of my PageRanks dropped?

Posted on By Mark Wilson
This content is 18 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

It’s well known that the Google index is based on the PageRank system, which can be viewed using the Google Toolbar.

Google page rank

But something strange has happened on this blog – the main blog entry page has a PageRank of 5, the parent website has a PageRank of 4, but the PageRanks for most of the child pages have dropped to zero.

Now I know that posts have been a bit thin on the ground this month (I’ve been busy at work, as well as working on another website), but I can’t understand why the rankings have dropped. I found this when I was using the site search feature to find something that I knew I’d written, but it didn’t come up. Entering site:markwilson.co.uk as a Google search brings back 258 results, but this blog has nearly 500 entries, plus archive pages and the parent website – where have all the others gone? Some recent entries, like the one on Tesco’s VoIP Service, have a PageRank of zero but still come back on a search (at the time of writing, searching for Tesco VOIP brings back my blog as the third listed entry). Others just don’t appear in search results at all. Meanwhile some old posts have PageRanks of 2 or 3.

I know (from my website statistics) that Googlebot is still dropping by every now and again. So far this month it accounts for 3319 hits from at least 207 visits – I just can’t figure out why so many pages have a PageRank of zero (which seems to be a penalty rank, rather than “not ranked yet” marking).

I don’t deliberately try to manipulate my search rankings, but steady posting of content has seem my PageRank rise to a reasonable level. I just don’t understand why my second-level pages are not appearing in the index. The only thing I can think of is that it’s something to do with my new markwilson.it domain, which is linked from this blog, and which redirects back to a page at markwilson.co.uk (but that page has no link to the blog at the time of writing).

I’ve just checked the syntax of my robots.txt file (and corrected some errors, but they’ve been there for months if not years). I’ve also added rel="nofollow" to any links to the markwilson.it domain. Now, I guess I’ll just have resubmit my URL to Google and see what happens…

Public/private key cryptography in plain(ish) English

Posted on By Mark Wilson
This content is 18 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Public key infrastructure (PKI) is one of those things that sounds like a good idea, but which I can never get my head around. It seems to involve so many terms to get to grips with and so, when Steve Lamb presented a “plain English” PKI session at Microsoft UK a few weeks back, I made sure that I was there.

Steve explained that a PKI can be used to secure e-mail (signed/encrypted messages), browsing (SSL authentication and encryption), code (authenticode), wireless network connectivity (PEAP and EAP-TLS), documents (rights management), networks (segmented with IPSec) and files (encrypted file system).

Before looking at PKI, it’s necessary to understand two forms of cryptography – symmetric and asymmetric. I described these last year in my introduction to IPSec post.

The important things to note about public key cryptography are that:

  • Knowledge of the encryption key doesn’t give knowledge of the decryption key.
  • The receiver of the information generates a pair of keys (either using a hardware security module or software) and publishes the private key in a directory.
  • What one key does, the other undoes – contrary to many texts, the information is not always encrypted with the recipients public key.

To some, this may sound like stating the obvious, but it is perfectly safe to publish a public key. In fact, that’s what a public key certificate does.

Having understood how a PKI is an asymmetric key distribution mechanism, we need a trust model to ensure that the public key really does belong to who it says it does. What if I were to generate a set of keys and publish the public key as my manager’s public key? Other people could send him information but he wouldn’t be able to read it because he wouldn’t have the private key; however I would have it – effectively I could read messages that were intended for my manager.

There are two potential methods to ensure that my manager’s public key really is his:

  • One could call him or meet with him and verify the fingerprint (hash) of the key, but that would be time consuming and is potentially error-prone.
  • Alternatively, one could employ a trusted third party to certify that the key really does belong to my manager by checking for a trusted digital signature on the key. The issue with this method is that the digital signature used to sign the key needs to be trusted too. Again, there are two methods of dealing with this:
    • A “web of trust” model, such as Phil Zimmermann‘s pretty good privacy (PGP) – upon which the GNU privacy guard (GPG) on Linux systems was built – where individuals digitally sign one another’s keys (and implicitly trust keys signed by friends/colleagues).
    • A trusted authority and “path of trust” model, using certificate authorities (CAs), where everyone trusts the root CA (e.g. VeriSign, Thawte, etc.) and the CA digitally signs the keys of anyone whose credentials have been checked using it’s published methods (producing a certificate). One CA may nominate another CA and they would automatically be trusted too, building a hierarchy of trust.

Most CAs will have multiple classes of trust, depending on the checks which have been performed. The class of the trust would normally be included within the certificate and the different levels of checking should be published in a document known as a certificate practice statement.

The analogy that I find useful here is one of writing and signing a cheque when paying for goods or services. I could write a cheque on any piece of paper, but the cheques that I write are trusted because they are written on my bank‘s paper – that bank is effectively a trusted CA. When I opened my account the bank would have performed various background checks on me and they also hold a reference of my signature, which can be checked against my cheques if required.

The padlock that indicates a secure website in most browsers also looks a bit like a handbag (UK English) or purse (US English)! The Internet Explorer 6 version looks like this Internet Explorer padlock and the Firefox 1.5 version is like this Firefox padlock. Steve Lamb has an analogy for users that I particularly like – “it’s safe to shop where you see the handbag”; however, it’s also important to note that the padlock (not really a handbag!) just means that SSL security is in use – it doesn’t mean that the site can automatically be trusted (it may be a phishing site) so it’s important to examine the certificate details by double clicking on the padlock.

Each verification method has its own advantages and disadvantages – web of trust can be considered more “trustworthy”, but it’s time-consuming and not well understood by the general public – CAs, whilst easy to deploy and manage, can be considered to be the tools of “Big Brother” and they have to be trusted implicitly.

Digital signatures work by calculating a short message digest (a hash) and encrypting this using the signatory’s private key, to provide a digital signature. The hash function should result in a unique output (although it’s theoretically possible that two messages could produce the same hash as a large volume of data is being represented by a smaller string) – the important point to note is that even the tiniest of changes will break the hash.

Creating a digital signature

Upon receipt, the recipient uses the signatory’s public key to decrypt the hash. Because the hash is generated using a one-way function, this cannot be expanded to access the data – instead, the data is transmitted with the signature and a new hash calculated by the recipient. If the two hashes match then the integrity of the message is proven. If not, then the message has almost certainly been tampered with (or at least damaged in transit).

Verifying a digital signature

Certificates are really just a method of publishing public keys (and guaranteeing their authenticity). The simplest certificate just contains information about the entity that is being certified to own a public key and the public key itself. The certificate is digitally signed by someone who is trusted – like a friend (for PGP) or a CA. Certificates are generally valid for a defined period (e.g. one year) and can be revoked using a certificate revocation list (CRL) or using the real-time equivalent, online certificate status protocol (OCSP). If the CRL or OCSP cannot be accessed, then a certificate is considered invalid. Certificates are analogous to a traditional passport in that a passport is issued by a trusted authority (e.g. the UK passport agency), is valid for a number of years and contains basic information about the holder as well as some form of identification (picture, signature, biometric data, etc.).

X.509 is the standard used for certificates, with version 3 supporting application-specific extensions, (e.g. authentication with certificates – the process that a browser will follow before displaying the padlock symbol to indicate that SSL is in use – authenticating the server to the client). Whether or not this certificate is issued by an external CA or an organisational (internal) CA is really a matter of choice between the level of trust placed in the certificate and how much the website owner is prepared to pay for a certificate (it’s unlikely that an external certificate will be required for a secure intranet site, whilst one may be expected for a major e-commerce site).

The SSL process works as follows:

  1. The browser (client) obtains the site (server) certificate.
  2. The digital signature is verified (so the client is sure that the public key really belongs to the site)
  3. To be sure that this is the actual site, not another site masquerading as the real site, the client challenges the server to encrypt a phrase. Because the server has the corresponding private key, it can encrypt the phrase and return it to the client.
  4. The client decrypts the phrase using the public key from the certificate – if the phrase matches the challenge, then the site is verified as authentic.

Most certificates can be considered safe – i.e. there is no need to protect them heavily as they only contain publicly available information. The certificate can be stored anywhere – in a file, on a USB token, on a memory-only smartcard, even printed; however private keys (and certificates that include them) are extremely vulnerable, requiring protected storage within the operating system or on a smartcard with cryptographic functionality (see below). Windows 2000 Server and Windows Server 2003 include a CA which can be used to issue and store certificates, especially within a company that is just looking to secure its own data. The Windows Server 2003 CA even supports auto-enrollment (i.e. where a certificate request is processed automatically), but what if the administrators within an organisation are not considered trustworthy? In that case, an external CA may be the only choice.

Most organisations use more than one root key for signing certificates. This is because it does not scale well, can be difficult to manage responsibility for in a large organisation and is dangerous if the key is compromised. Instead, certificate hierarchies can be established, with a CA root certificate at the top, and multiple levels of CA within the organisation. Typically the root CA is installed, then taken offline once the subordinate CAs have been installed. Because the root is offline, it cannot be compromised, which is important because complete trust is placed in the root CA. With this model, validating a certificate possibly involves validating a path of trust – essentially this is just checking the digital signature but it may be necessary to walk the path of all subordinate CAs until the root is reached (or a subordinate that is explicitly trusted). Cross certification is also possible by exporting and importing certificate paths between CA hierarchies.

The list of trusted root CAs increases with each Windows service pack. Some certificates can be obtained without payment, even those included in the list of Windows’ trusted root CAs. Whilst these are as valid as any other certificate, they are unlikely to have undergone such stringent checks and so the level of trust that can be placed in them may not be deemed sufficient by some organisations. If this is a concern, then it can be cleared down from within the browser, using group policy or via a script – the only client impact will be a (possibly confusing) message asking if the certificate issuer should be added to the list of trusted authorities when a site is accessed.

Smartcards are often perceived as a useful second factor for authentication purposes, but it’s useful to note that not all smartcards are equal. In fact, not all smartcards are smart! Some cards are really just a memory chip and are not recommended for storing a private key used to verify identity. More expensive smartcards are cryptographically enabled, meaning that the key never has to leave the smartcard, with all processing done on the smartcard chip. Additional protection can also be included (e.g. biometric measures) as well as self-destruction where the card is known to have been compromised.

It’s worth noting that in the UK, organisations that encrypt data and do not have the means to decrypt it can fall foul of the regulation of investigatory powers (RIP) act (2000). There is an alternative – leaving the keys in escrow – but that is tantamount to leaving the keys with the government. Instead, the recommended practice for managed environments with encryption is to store keys in a location that is encrypted with the key recovery operator’s key – that way the keys can be recovered by an authorised user, if required.

After attending Steve’s session, I came away feeling that maybe PKI is not so complex after all. Steve’s recommendations were to set up a test environment and investigate further; to minimise the scope of an initial implementation; and to read up on certificate practice and certificate practice statements (which should be viewed as being more important than the technology itself if defending the trustworthiness of a certificate in court).

For anyone implementing PKI in a Microsoft infrastructure, there’s more information on PKI at the Microsoft website.

The OSI reference model and how it relates to TCP/IP

Posted on By Mark Wilson
This content is 18 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Earlier today, whilst on a client site, waiting for a PC to rebuild (5 times – and I thought my desktop support days were over… maybe that’s why they should be…), I saw a diagram of the open systems interconnection (OSI) reference model pinned up above a desk. I’ve seen many OSI model representations over the years, but this one was probably the clearest example I’ve seen in a while (especially for TCP/IP), so I’ve reproduced it here:

MOM 2005 architecture

Configuring wireless Ethernet with SuSE Linux 10.0

Posted on By Mark Wilson
This content is 18 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Alex and I were debating the pros and cons of various operating systems during our geekfest (working on my latest website project, in the pub) last weekend – he’s just bought a new Mac (and works with them all day), so, like most Mac users I know, he can’t see why anyone would possibly want to use anything else (not quite true, but that’s the gist of it). Meanwhile I sat down at his Mac and couldn’t even work the mouse properly to open up Firefox and pull some information off the ‘net. I complained that standard keyboard shortcuts didn’t work (I had to use the Apple key instead of control) and he said it’s because I only use Windows. I disputed that – I like GNOME on Linux – and the reason I like it is that it works like Windows, only better. It’s got a cleaner interface but most of the keyboard shortcuts that I know still work. But even Linux is not ready for complete newbies. It’s come a long way since I first used it back in 1993 – in fact it’s advancing at a tremendous pace – but even Linux Format magazine acknowledges this month that it needs to be approached “with an awareness that it takes time and patience to use properly”. Linux is not for everyone. I’ve got nearly 20 years of PC experience under my belt (12 years designing, supporting and implementing systems using Microsoft software), and I’m still struggling with Linux (although getting on much better since I spent last week learning a bit about Red Hat Enterprise Linux).

So, what’s the point of this rambing? Well, last night, after weeks of wrangling, I finally got a non-Windows operating system to connect to my wireless network. I gave up trying to do this on Solaris (after the Solaris NDIS wrapper toolkit failed to compile on my system and I couldn’t get a satisfactory answer to my post at the OpenSolaris.org forums) and instead went for a popular Linux distro (SuSE 10.0, which Novell very kindly sent me a copy of a few weeks back).

There are many reports on how to do this out there on the ‘net, but none of them worked exactly for me. What follows is what I did with SuSE 10.0 on an IBM ThinkPad T40, with a D-Link DWL-G630 PCMCIA card and a D-Link DWL-2000AP+ access point, configured to use WPA-PSK (TKIP) and proven to work using a selection of Windows clients.

SuSE 10.0 comes with packages for NdisWrapper (v1.2), wireless tools (v28 pre-8) and WPA supplicant (v0.4.4), I used YaST to check that these were all installed and located the netrt61g.inf, rt61.cat and rt61.sys files from the CD supplied with my network card. I don’t think the .cat file is required, but I copied them all to /tmp anyway.

Next, following the advice for installing NdisWrapper on SuSE Professional 9.2, I ran the following commands from a terminal window (logged in a root) to install the network card:

cd /tmp
ndiswrapper -i drivername.inf

In my case this was netrt61g.inf, and the response was Installing netrt61g. Next, I entered:

ndiswrapper -l

to check the status of the NDIS drivers and saw the response:

Installed ndis drivers:
netrt61g driver present

The next part is to load the module, using:

modprobe ndiswrapper

This doesn’t return a response, but using iwconfig should return details for a new interface (in my case it was wlan0). At this point, I hadn’t yet inserted the card, but all seemed fine with the card driver configuration.

I then used YaST to configure the new wlan0 interface (although I could have made the edits manually, YaST saves me from missing something). The instructions I followed used YaST to edit the system configuration (System, /etc/sysconfig Editor), although some settings need to be added into text files manually, so they might as well all be done that way:

  • Add MODULES_LOADED_ON_BOOT="ndiswrapper" to /etc/sysconfig/kernel
  • Add DHCLIENT_MODIFY_RESOLVE_CONF='yes' and DHCLIENT_SET_DEFAULT_ROUTE='yes' to /etc/sysconfig/network/ifcfg-wlan-wlan0

That should be it for a basic wireless Ethernet configuration (although it may also be necessary to set any other network interfaces to start on cable connection, on hotplug, etc., rather than at boot time). For those of us using a secure network, there’s still more to do as it’s necessary to configure WPA Supplicant. It should be as simple as configuring /etc/wpa_supplicant.conf, then issuing a few simple commands:

ifconfig wlan0 up
wpa_supplicant -Dndiswrapper -iwlan0 -c/etc/wpa_supplicant.conf -dd

Sadly, that didn’t work for me. Even now, I’m not sure that the contents of my /etc/wpa_supplicant.conf file are correct – that’s why I haven’t published them here; however it maybe useful to know that the package also includes command line (wpa_cli) and graphical (wpa_gui) utilities for troubleshooting and managing the interface. wpa_cli was pre-installed as part of the package on my system, but I didn’t get anywhere until I obtained wpa_gui from the latest stable release of wpa_supplicant (v0.4.8).

To do this, I needed to add the gcc (v4.0.2), gcc-c++ (v4.0.2) and qt3-devel (v3.3.4) packages to my installation, then compile and install wpa_gui using:

PATH=$QTDIR/bin:$PATH
make wpa_gui
cp wpa_gui /usr/sbin

Only after typing wpa_gui -iwlan0 was I able to scan for an AP and locate the available networks:

wpa_gui scanning for networks

Then I could connect using the appropriate WPA key:

wpa_gui scanning for networks

wpa_gui scanning for networks

The connection doesn’t last long (it drops a few seconds after the 4-way handshake shown above), but at least it seems I have a working configuration (if not a stable one…).

So, it wasn’t easy. In fact, I’d say that wireless support is one of Linux’s weak spots right now, not helped by the fact that the device manufacturers generally only support Windows. Even now, I have some issues – like that my connection drops and then I can’t re-establish it – but I think that might be an issue with using Windows drivers and NdisWrapper. At least I know that I can get a connection – and that’s a step in the right direction.

Why open source software is not really free

Posted on By Mark Wilson
This content is 18 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

There’s a common misconception that open source software is free – as in doesn’t cost anything – and conversely that proprietary software is expensive.

I’d often wondered how this was aligned with the sale of packaged distributions of free software (it turns out I’m not the only one – a UK trading standards department were also confused by the sale of Firefox CDs – thanks to Slashdot via Slashdot Review for causing me to laugh out loud about that one…). Actually, it turns out that open source software is only free as in free speech – not as in free of charge. Sometimes it is free of charge too, but the two most common open source licensing models (GNU and BSD) do not prohibit the sale of “free software”.

GNU (a recursive name – GNU’s Not Unix) is a project, started by Richard Stallman in 1984 to create a free Unix clone, managed by the free software foundation (GNU/Linux is the kernel developed as a result of that project). GNU’s definition of free software says in part:

    • The freedom to run the program, for any purpose (freedom 0).
    • The freedom to study how the program works, and adapt it to your needs (freedom 1). Access to the source code is a precondition for this.
    • The freedom to redistribute copies so you can help your neighbor (freedom 2).
    • The freedom to improve the program, and release your improvements to the public, so that the whole community benefits (freedom 3). Access to the source code is a precondition for this.

    2. “Free software is a matter of the users’ freedom to run, copy, distribute, study, change and improve the software. More precisely, it refers to four kinds of freedom, for the users of the software:A program is free software if users have all of these freedoms. Thus, you should be free to redistribute copies, either with or without modifications, either gratis or charging a fee for distribution, to anyone anywhere…

    …’free software’ does not mean ‘non-commercial’.”

The GNU general public license (GPL) encourages free software, but all enhancements and changes to GPL software must also be left as GPL. In effect, the software is free to enhance, but not necessarily free to purchase.

Where code is derived from the University of California at Berkeley BSD project, a separate licensing agreement applies. Many commercial software vendors prefer to use the BSD license, because it lets them wrap open source code up in a proprietary product. As Linux Format magazine paraphrased this month, “In a nutshell, the BSD licence says, ‘do what you like with the code – just don’t claim you wrote it'”. The BSD code would still be free, but the developers don’t have to release all of the source code for the entire product.

Whilst I’m writing about non-copyright licensing agreements, it’s worth mentioning creative commons. Not limited to software products, this is a licensing alternative to copyright for all creative works, building on the “all rights reserved” concept of traditional copyright to offer a voluntary “some rights reserved” approach.

I’m really interested in the rise of Linux as an alternative to Windows; however it’s not about stripping out software purchase costs. Purchasing a version of Linux with a predictable development cycle and a support entitlement (e.g. Red Hat Enterprise Linux or Novell/SUSE Linux Enterprise) can be just as (or even significantly more) expensive as a copy of Windows and management costs need to be considered too. For as long as the majority of IT organisations are geared up to provide almost exclusively Windows support, Linux support costs will be higher too.

A quick introduction to Linux for Windows administrators

Posted on By Mark Wilson
This content is 18 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Linux penguinI’ve written previously about my various attempts to cross-train in Windows and Unix. Recently, I began running Sun Solaris 10 x86 on one of my machines, more recently I’ve installed SUSE Linux 10.0 and this week, I’m attending a training course to learn about Red Hat Enterprise Linux.

What follows might be useful for anyone thinking of making the switch (or just picking up some new skills). I should stress that I’m a Unix/Linux newbie (unless you count some Unix systems programming back at uni’ in the early 90s) so these notes are probably incomplete and I might come back and edit them later. I don’t intend this to be a guide for integrating Linux and Windows either – more of a quick conversion for Windows administrators starting to work with Linux. Also, whilst these notes are based on Red Hat Enterprise Linux 4, they should hold true for most recent Linux distributions (I’ve tested them on SUSE Linux 10.0) and they shouldn’t be too alien for other Unix variants (although the commands may be a little different).

Whatever the Linux distribution, the kernel is controlled by kernel.org. This is the part of the operating system based on the original work by Linus Torvalds. The differences between Linux variants come at the next level with the various utilities added as part of individual distributions, including the graphical environments (e.g. GNOME and KDE).

Some vendors (e.g. Red Hat and Novell) have split their products into a free-to-download version with frequent upgrades and rapid adoption of new technology (e.g. Fedora, SUSE) and a more stable version with predictable release cycles and a subscription-based licensing model including support (e.g. Red Hat Enterprise Linux, SUSE Enterprise Linux), aimed at corporates who need to maintain standards. Some distributions also include utilities for keeping the system up-to-date (although these may also require an appropriate entitlement).

Installation of a Linux system is generally straightforward. The major distributions make life easy with bootable CDs and DVDs and comprehensive setup/installation routines (e.g. YaST). Having said that, if problems are encountered, they are not always easy to resolve (it took me considerable time to resolve a recent issue with installing SUSE 10.0 on an IBM ThinkPad).

Once installed, Linux can be used in either command line interface (CLI) or graphical user interface (GUI) mode. Unlike modern Windows operating systems, the Linux GUI is separate from the operating system itself and it is possible to run several CLI and GUI sessions (called virtual consoles) simultaneously. By default Ctrl-Alt-F1 to Ctrl-Alt-F6 are CLI user virtual consoles, whilst Ctrl-Alt-F7 will run a GUI interface. Multiple GUI sessions can be started using the startx command.

The Linux root user is analogous to the Windows administrator but (largely because Linux expects users logged in as root to know what they are doing) Linux doesn’t tend to issue “are you sure?” prompts and so it is far easier to perform something destructive by mistake when logged in as root. Although it’s also good practice to run as an unprivileged user in Windows, this should definitely be the norm in Windows. Many GUI applications (and some CLI ones) allow for escalation of privileges (in a similar manner to the user access protection feature in Windows Vista).

As for Windows (with command, cmd, wsh and soon msh), Linux has a variety of shells/command interpreters available for use. Linux distributions use the Bourne-again shell (bash) by default but may also ship with other shells including the original Bourne shell (sh), C shell (csh) and Korn shell (ksh).

Linux uses the X Window system for GUI operation; however X Window doesn’t dictate the look and feel – it is simply an application that provides the ability to draw on the screen. X Window is a client/server application, with the X server handling the monitor, keyboard and mouse and various X clients interacting with the X server. Examples of these X clients include the display manager (handling logins), the window manager that controls the look and feel (e.g. Metacity, KWin), the desktop environment (e.g. GNOME, KDE) and a variety of other x client applications (file browsers, web browsers, terminals, etc.). The two main X Window systems are XOrg and XFree86.

Linux has a system of runlevels, similar to the Windows concepts of recovery console, the various safe modes, and normal operation. For Linux, the runlevels are:

  • 0 – shut down.
  • 1 – systems maintenance (single user mode).
  • 2 – multi-user (no file sharing).
  • 3 – multi-user with file sharing (effectively a running system without a GUI).
  • 4 – not implemented.
  • 5 – (default) fully running.
  • 6 – reboot.

The init runlevel command is used to switch between runlevels but beware that some Unix versions will use different runlevels (e.g. init 5 will power off a Solaris system).

Whereas Windows systems store configuration information in a plethora of locations (registry, file system, Active Directory, etc.), Linux generally uses a series of text files; however, just like in Windows, these may be spread all over the file system. This is probably the most confusing element for an administrator converting from Windows and the following is a list of likely locations from the file system hierarchy in which to find information:

  • Home directories (/root, /home/username).
  • Binaries (essential in /bin, non-essential in /usr/bin, third-party in /usr/local/bin).
  • System binaries (essential in /sbin, non-essential in /usr/sbin, third-party in /usr/local/sbin).
  • Foreign file system mountpoints (/media, /mnt).
  • System configuration (/etc).
  • Temporary files (/tmp).
  • Kernel and bootloader (/boot).
  • Server data such as logs and spool files (/var, /srv).
  • System information (/proc, /sys).
  • Libraries (essential in /lib, non-essential in /usr/lib, third-party in /usr/local/lib).

Everything in Linux is represented as a file – even hardware (files within the /dev and /proc directories – note that files in /proc are memory-based, rather than disk-based). Hard disks use a naming convention with hd representing an IDE hard disk and sd representing a SCSI hard disk. This is followed with a letter to distinguish the first disk as a, second disk as b, etc. Finally, partition numbers are indicated with a numeric suffix, so /dev/hda1 is the first partition on the first IDE disk. The partition table can be listed with fdisk -l.

Although Linux does support directory services and other authentication mechanisms using pluggable authentication modules (PAMs), some local users and groups will inevitably be required. Users may be created using the useradd command and groups with groupadd. Each Linux user has a numeric user identifier (UID) – root is always 0. Users are associated with one or more groups (a primary group and optional secondary groups), each of which is identified by its group identifier – the GID. User information, including name, UID, default GID, home directory and shell, is stored in the /etc/passwd file. Group information is stored in /etc/group. Even though the passwd command is used to change a password, passwords are not actually stored in /etc/passwd – instead they are stored as a password hash in /etc/shadow, along with details of when the password was last changed and the account expiration policy. System-wide account expiration policies can be defined in /etc/login.defs.

Unlike in Windows, Linux filenames are case sensitive. Linux, in common with other Unix variants, uses a discretionary access control permissions model with the concept of owner, group and others, controlled using the chmod command. Each of these can be marked with read, write or execute flags, as well as special flags (set user ID, set group ID and sticky) and another flag which indicates if a file is a directory.

For regular files, read means examine the file contents, write means modify the file contents and execute means run the file as a command. For directories, read means list directory contents, write means add or remove files and execute means change directory into the directory and view its properties.

When talking about file permissions, they are often expressed as a 3 (or sometimes 4) digit number. If these numbers make no sense, think of each set of permissions (special, owner, group and others) in binary:

Linux file permissions

4+2=6, so 0666 (usually written as 666) is -rw-rw-rw-. Similarly 4+2+1=7 so 0777 (777) is -rwxrwxrwx. More commonly, 0644 is -rw-r–r–.

Standard Linux file permissions are 0666 (-rw-rw-rw-) for files and 0777 (drwxrwxrwx) for directories although these are masked with a umask such as 0022 to remove the unnecessarily high permissions for group and others (0022 would make 0666 become 0644 and 0777 become 0755).

In common with other systems that use Kerberos authentication (including domain-joined Windows PCs), time synchronisation is critical to Linux systems. It’s not so important that the correct time is used, so much as that all the systems agree on a common time, but in any case the date can be set using the date command and Linux systems also have support for the network time protocol (NTP).

Linux uses TCP/IP as its networking protocol suite. Network devices are named by type and a numeric instance number. Ethernet is eth (eth0, eth1, etc.), token-ring is tr, fibre channel is fddi, dial-up and ADSL are ppp and localhost or loopback (127.0.0.1) is lo. In some circumstances, more than one connection may run using the same piece of hardware, for example Ethernet (eth0) is used for an ADSL connection, but ppp0 will be the connection tunnelled through the Ethernet link. Virtual network devices can also be created, e.g. eth0:1. It’s worth noting that changes to interface configurations will not become effective until an interface is deactivated and activated again. This can be performed from the command line using ifdown interfacename and ifup interfacename.

Linux printing is usually achieved using the common Unix printing system (CUPS); however, just as in Windows there is support for local and networked printers, with a variety of drivers, Printing is one area which is often easiest to configure using the GUI.

Recent versions of Linux include a kernel feature known as secure Linux (SELinux), which replaces the traditional discretionary access control model described earlier, with policy-based mandatory access controls which enforce security within a defined context. As SELinux is relatively new feature, many applications and services are not aware of it and whilst disabling SELinux is discouraged, it can be set not to enforce policy (although violations will still be logged to /var/log/messages). Another security feature that should not be alien in principle to Windows administrators is the built-in packet filtering firewall, administered using the iptables command.

So that’s it – a quick introduction to Linux for Windows administrators. To find out more, I recommend installing one of the free distributions and giving it a go for yourself. For help, try one of the following:

  • whatis commandname.
  • commandname --help.
  • man commandname (manual pages for many commands).
  • info commandname (texinfo pages for some commands).
  • Files in /usr/share/doc/packagename.
  • Website for the Linux distribution in use (e.g. Fedora, Debian, etc.).
  • The Linux documentation project.

If all else, fails, there’s a whole load of information that can be found by searching Google.

GRUB error 18 when installing SUSE 10 on an IBM ThinkPad

Posted on By Mark Wilson
This content is 18 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

A few days ago, I finally managed to solve a problem that had been preventing me from installing SUSE Linux 10.0 on my IBM ThinkPad T40 for the last couple of weeks. My problem was, that the first stage of setup ran with no difficulties at all but after the initial reboot I was greeted with the following error:

GRUB Loading stage1.5…

GRUB loading, please wait…
Error 18

GRUB error 18 means “selected cylinder exceeds maximum supported by BIOS” but as the disk is the original one supplied with the PC, I thought that was unlikely to be an issue. There is, however, another variable in the equation with when using a ThinkPad.

Rather than supplying recovery CDs with its notebooks, Lenovo (IBM) positions its ThinkVantage software products as a differentiator and a reason to charge a premium price for its hardware – actually, my ThinkPad is by far and away the best hardware I have access to – comparable Dell machines have been very poorly built, although the HP (Compaq) and Fujitsu-Siemens equipment that I use has been pretty good. Part of the ThinkVantage product range is the rescue and recovery with rapid restore software, combined with the Access IBM key which uses a hidden partition on the disk – the Access IBM pre-desktop area or hidden protected area (HPA).

It was this hidden partition that caused me difficulties. There are three options for controlling access to the predesktop area in the BIOS – secure, normal and disabled. Normal (the default setting) allows changes to the pre-desktop area but the contents are hidden from the operating system whilst secure prohibits all user- or software-initiated changes and disabled makes the pre-desktop area visible and reclaimable for use.

After trying various pre-desktop area BIOS settings I noticed that the amount of disk space available to SUSE varied between 34.2GB in secure mode and 37.2GB in normal mode. It seems that even with the normal selection in BIOS, SUSE setup had been able to detect the full disk, and had installed the kernel on a section of the disk reserved for the pre-desktop area (which was then unavailable at boot time – causing the GRUB error).

In summary, if installing SUSE (or any operating system I guess) on a ThinkPad, set the predesktop area to secure before commencing installation – Sharad Popli has more information about this in his SUSE Linux, WinXP and Access IBM on the ThinkPad T43 article. I now have SUSE installed, but have a corrupt HPA. Thankfully my PC is still under warranty so Lenovo are sending me some recovery CDs without charge (my experience of their technical support has been excellent).

Overall, I was impressed with the SUSE setup – very straightforward compared to my earlier experiences of installing Unix and Unix-like operating systems. I also know (from my limited tinkering with Sun Solaris) that I like the GNOME desktop – let’s see how I get on with using the product over the next few weeks (and how it stacks up against the competition, as I’m attending a Red Hat Enterprise Linux course all of this week).

How to (radically) change the Windows XP graphical user interface

Posted on By Mark Wilson
This content is 18 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Earlier today, I saw one of my colleagues running what looked like the new Windows Vista graphical user interface on his Windows XP PC and it turned out to be one of the many visual enhancements available from CrystalXP.Net. I haven’t installed any of them yet, but may well give them a go soon as it looks like there’s some really impressive Windows interface customisation available, along with artwork based on Tux the Linux penguin and other mascots.