Category Archives: Linux

Kickstart and DHCP

Posted on by
Reply

Here’s a tangled web to unpick at your leisure!

Back in December, I finally switched off my 7 year-old laptop (a sturdy Thinkpad X40) that had been doing practically nothing except running Windows XP, on which was running my ISP’s Internet Connection software, and also sharing that Internet connection with Microsoft’s built-in ICS (“Internet Connection Sharing”). Effectively, my Thinkpad had been running as a router for years. In its place, I plugged the wireless Internet USB device into a Scientific Linux server and switched on IP forwarding: a little bit of re-configuration of my various clients (laptops, netbooks, desktops) and all could still access the Internet, but now without a flaky laptop (or a flaky XP installation) in the path.

So far so good.

Cut to today, when I’m building a Centos 6.2 virtual machine, using my now-standard technique of “installation over the network” (as described here). Every time I started the installation, it bombed out with a warning that ‘Network Manager couldn’t configure the eth0 interface’. I tried Scientific Linux 6.1, which I’ve used a bazillion times in the past… same story.

So I fiddled. Since it was apparently a networking problem, I switched my virtual machine from “bridged” to “NAT” and tried Scientific Linux 6.1 again: and it worked! I didn’t pause to think why NAT worked when bridged didn’t, but simply ticked it off as ‘fixed’.

Back, therefore, to trying to build a Centos 6.2 VM, this time using the now-proven “NAT” technique. Except that this time, it didn’t work. It started to, sure enough: at least I didn’t get the ‘Network Manager can’t configure’ error again. Indeed, the installation process correctly read my kickstart file and a couple of the installation files as stored on my web server. But then it failed to read the install.img file:

Now that just made no sense to me: the path mentioned was absolutely, 100% guaranteed to be correct… and I checked it multiple times to be certain of that. What’s more, “install.img” is merely the third file read during the installation process (updates.img and product.img are read first). So how come the network was fine for two files but bombed out on the third?!

I spent the best part of a day checking and triple-checking my entire setup: physical host to virtual web server connectivity was fine; paths as specified in my kickstart file were fine; IP configuration as specified in the kickstart file was fine… all dead-ends.

And then, for no particular reason that I can now recall, I decided to do a quick yum install dhcp on my web server. A slightly less quick edit of /etc/dhcp/dhcpd.conf and I had myself a working DHCP server.

And guess what? The Centos 6.2 install worked perfectly!

What’s more, I then went back and tried both Centos 6.2 and Scientific Linux 6.1 installations with the “bridged” network option, and both of them worked fine too!

Apparently, therefore, DHCP is essential for network installs of Linux. Why hadn’t I ever noticed this before? Because of Microsoft, that’s why!! (They have to be responsible for all the bad things that happen, right?) The Internet Connection Sharing software my faithful Thinkpad had been using to act as a router automatically switches on both DNS and DHCP. That ancient laptop had, in fact, been this house’s DHCP server without me ever really worrying about it. When I retired it in December, therefore, I lost DHCP -and although I’d been sharing the Internet connection on the Linux box, I’d not installed DHCP anywhere to take its place. I knew all of that: but it didn’t concern me.

The reason I wasn’t concerned is that we simply don’t use DHCP in this house! (Not knowingly, anyway!!) All my servers, desktops, laptops and what-have-you are carefully assigned fixed IP addresses. I even have a spreadsheet showing which addresses have been allocated and which are free! So, since we don’t use DHCP, losing a DHCP server by retiring ICS really didn’t bother me.

But suddenly, today we have proof that DHCP was necessary after all :-(

Now, thinking about this with 20-20 hindsight , it’s all a bit obvious. How can a server you’re trying to build talk to a remote web server unless it already has acquired an IP address? Sure, the kickstart file it finds on the web server will eventually grant a proper, static IP address… but how does it get to read that file in the first place unless it already has some form of network communication with the remote server on which it’s stored?

That initial IP address is acquired easily in NAT mode: it’s the same address your physical host uses. Hence both builds in NAT mode at least started off fine, and Scientific Linux’s was completely successful. When you run in bridged network mode, though, your VMs have to acquire that initial IP address the same way any physical machine would: from a DHCP server. And since I didn’t have a DHCP server any more, not even a non-obvious one from Microsoft that’s surreptitiously switched on by enabling ICS, all my bridged builds started to fail.

The moral of the story: you need a DHCP server if you’re going to do networked installs of Linux, even if you don’t intend using DHCP after the initial installation has completed.

Now, a trawl around Google tells me that this is not necessarily a cast-iron rule: apparently, there are non-DHCP ways around this. But I’ve not tried the workaround suggested -and DHCP is so trivially easy to get going anyway that it’s not something I’m desperate to avoid using.

Of course, one mystery remains: in NAT mode without a DHCP server, the Centos installation started well enough and then bombed out; in exactly the same configuration, the Scientific Linux install sailed through the whole thing without incident. It would seem as if Centos starts off by using the physical host’s IP address (thanks to NAT) but then tries to switch to acquiring its own address (which, without a DHCP server, it can’t do), whereas Scientific Linux appears to make do with its initial IP address just fine.

Why this difference in behaviour? As I say, it’s a mystery at this stage -which makes this sort of thing fun and infuriating in equal measure, I guess!

VirtualBox Installations on Scientific Linux

Posted on by
3

I’ve mentioned previously that my preferred virtualization platform is VMware Workstation. That remains true …but VirtualBox does have the distinct advantage of being free-of-charge. So unless I want to insist that my readers find AU$291.50 for VMware’s offering, it behooves me instead, from time to time, to use the virtualization platform I know we can all afford.

So here is my two-minute recipe guide to getting the latest VirtualBox product installed (for zero dollars!) on Scientific Linux 6.1. (You could always just download the relevant rpm and install it directly, but I prefer to do all my package management via yum wherever possible, so that’s the approach described here).

1. Get the gpg key

VirtualBox is supplied as a bunch of rpm packages which have been digitally signed. By checking the signature, you know no-one’s messed about with the packages before they reached you. It therefore makes sense to obtain and install the digital key needed to do that signature check. It’s easy to do, as root, at a command prompt, by issuing these two commands:

wget http://download.virtualbox.org/virtualbox/debian/oracle_vbox.asc
rpm --import oracle_vbox.asc

2. Create the yum repository

Again as root, issue this command to create a new, blank repository file:

gedit /etc/yum.repos.d/virtualbox.repo

Now paste in these contents to the empty file:

[virtualbox]
name=RHEL/CentOS-$releasever / $basearch - VirtualBox
baseurl=http://download.virtualbox.org/virtualbox/rpm/rhel/6.0/$basearch
enabled=1
gpgcheck=1
gpgkey=http://download.virtualbox.org/virtualbox/debian/oracle_vbox.asc

Save the file changes and close down gedit. Just in passing, you might note that I’ve changed this file from the version which Oracle themselves makes available on the VirtualBox website. Specifically, their baseurl uses an environment variable, called $releasever, where I have hard-coded in the number 6.0. The trouble, of course, is that if you are using the latest versions of Scientific Linux or Centos, you’ll be picking up a releasever of 6.1 or 6.2 …and no such directory exists on the VirtualBox servers. You’d need to manually check out those server’s directory structure to see if that situation changes over time.

3. Install the Software

As root once more, the following one-liner will display all the different versions of VirtualBox that are available for installation:

yum search VirtualBox

You might see this sort of output in return:

Loaded plugins: refresh-packagekit
virtualbox | 951 B 00:00
virtualbox/primary | 4.4 kB 00:00
virtualbox 17/17
============== N/S Matched: VirtualBox ==============
VirtualBox-3.2.x86_64 : Oracle VM VirtualBox
VirtualBox-4.0.x86_64 : Oracle VM VirtualBox
VirtualBox-4.1.x86_64 : Oracle VM VirtualBox

This shows that Oracle keeps a couple of older versions of the software alive and available, should you need to use them. Most people, though, will really only need the latest version, so pick that from the list and issue an appropriate “yum install” command. In my case, given the above output, this command will do the right thing:

yum -y install VirtualBox-4.1.x86_64

It’s a 58MB download or so, and as it’s installed you might see this message appear:

Running Transaction
 Installing : VirtualBox-4.1-4.1.8_75467_rhel6-1.x86_64 1/1

Creating group 'vboxusers'. VM users must be member of that group!

This gives you the clue to the last stage of the installation process…

4. Assigning Group Privileges

The software installation has created a new O/S group, called vboxusers, but it won’t have made your user account a member of that group. That needs to be fixed.

From the Gnome top panel, clieck System > Administration > Users and Groups. Find your user details on the Users tab and double-click the entry. Switch to the Groups tab, scroll down and check the vboxusers group name:

Click [OK] to save the change, and you’re done, though you’ll need to log off and back on before the group membership changes take practical effect.

If you prefer doing everything at the command line, just edit /etc/group (as root, of course) and add a :your-username entry to the end of the vboxusers line, which will probably be the last line of the file. In my case, for example, the line ended up reading vboxusers:x:501:hjr -which simply means that user ‘hjr’ is now a member of the vboxusers group. (Again, it’ll take a log off and fresh log on before the new group membership actually takes effect).

Either way, you’re now done and can run the VirtualBox program successfully, with the program launcher being found in Applications > System Tools.

5. USB Support

The version of VirtualBox installed by the above procedure will be unable to access USB 2.0 devices that might be plugged into your physical host. However, this shortcoming can be fixed by installing the “Oracle/VirtualBox Extension Pack”. Download it from the VirtualBox website and then just double-click the file when the download completes. You should see the following appear:

Click the [Install] button there, agree to the license, authenticate as root and all should be done in a matter of seconds. You’re now ready to build and run fully-functional virtual machines.

Corrupt Zips… or not!

Posted on by
Reply

I created a 78GB zip file, with the Windows version of 7-zip, back in November. Today, for the first time, I tried unzipping it on my Linux desktop: a simple right-click and Extract Here and things looked good: all the file were there in all the right places, properly named and ready to go…

Unfortunately, when I then tried to do anything with the files produced by the extraction process, all failed to work: music and video files simply refused to play in VLC, Movie Player or anything else, for example.

I feared the worst: a corrupt zip file. I was about to shrug my shoulders, delete the zip file and chalk it up to experience when I thought, ‘let’s try to repair the zip!’ Nothing ventured, nothing gained after all… and if the repairs failed to work, I’d at least be no worse off than I was already.

Two programs suggested themselves, thanks to Google (both Windows-only, so run in a virtual machine).

First up: Disk Internals. Small download, apparently free, nice wizard point-and-click interface. A bit slow identifying anything capable of being recovered… and, in the end, it only output a couple of hundred files (out of over 3800 in the original zip) before falling over in a heap and crashing. None of them was usable.

So, second try: Object Fix Zip. Another small download, standard Windows installation and simple wizard interface. On its first run, it prompted me for a password to the zip file… and it was at that point I suddenly remembered that I had, indeed, password-protected the original zip file. I also suddenly realised that the Disk Internals program had never prompted me for a password… no wonder that first program had been unable to recover anything usable!

Even more interesting, Object Fix Zip prompted me for a password… and then kept prompting me for each file it encountered within the zip. It would accept the password I typed, extract a file from the zip, move onto the next file within the zip and then prompt me again. Then I noticed that (a) every file it appeared to extract was unusable and (b) I could type a password I knew to be rubbish… and the program would continue to extract, move on, re-prompt.

That in turn made me realise something: the Linux Extract Here menu option had never prompted me for a password at all… and its outputs were useless. The Disk Internals repair tool had not prompted me for a password either… its outputs were similarly useless. Object Fix was at least prompting me for a password … but its continual prompts regardless of what I typed in seemed to suggest that maybe I was providing an incorrect password all along.

So then the penny dropped: could the original idea that my zip file was corrupt be merely the result of the non-supply of a password, or the supply of a wrong password?

I re-ran Object Fix a couple of times more, each time supplying a different plausible password. And Lo! On one of these subsequent runs, it accepted the password and stopped asking for it after that. Clearly, when the right password was supplied, it only needed to be told it once. And, even better, the files being output by the Object Fix tool were (drum roll, please)… completely usable.

To cut a long story short, I then went back to my Linux desktop and used the Linux equivalent of 7zip (called p7zip, but invoked with the command 7za) to extract the file:

7za x /path/filename.zipghjghjgh

…and this program properly prompted me to supply a password. When I typed in a password I knew couldn’t possibly be correct, the program at least told me there was a problem:

CRC Failed in encrypted file. Wrong password?

The second part of that message is, at least, a good, strong clue as to what’s wrong, although you could get the wrong idea entirely if you paid any attention to that bit about CRC  failing. A genuinely corrupt file would generate warnings about CRC failures, after all!

So, finally, I re-ran 7za with what I knew by this time to be the correct password… and the whole thing extracted itself without a hitch. All files were usable, all 78GB of data were back safely from the brink!

In summary, if you think your zip file is corrupt, make sure it wasn’t originally password-protected. If it was password-protected, don’t expect Linux’s ‘extract here’ functionality to prompt you for the password -and expect its output to be garbage as a result. A program like p7zip will prompt you for a password appropriately, but may not be obvious about it if the password you supply turns out to be incorrect. And don’t give up on your zip until you’ve exhausted every conceivable password!

Linux Equivalent of CPU-Z?

Posted on by
8

I’d be a bit surprised if any of my readers weren’t already aware of CPU-Z: it’s a very handy utility to run on a Windows PC when you are contemplating buying new RAM (and need to know what type of RAM your motherboard takes), or wondering whether your CPU has the hardware virtualisation extensions:

It has a couple of flaws, however. The first is that, like a lot of Windows freeware these days, you have to be careful during the installation process, because it will suggest by default to install the Ask toolbar and to change your browser’s home page. Why anyone, ever, thought that would be a good thing for a user to experience, I have never worked out -but it’s certainly annoying to me.

The second problem is that it’s a Wndows-only affair. If you want to check these sorts of hardware details when you’re running Linux, it’s not the tool for you!

So is there a Linux equivalent of CPU-Z?

Indeed there is -and, if you’re running Scientific Linux 6.1, at least, it’s already installed and you merely have to invoke it. The program is called dmidecode. It’s a text utility (none of your twittering GUIs here, thank you very much) which must be run as root (you’ll get ‘permission denied’ errors if you try running it as yourself). As root, therefore, issue this sort of command:

dmidecode | more

…and you’ll see stuff that looks like this:

[root@dirac ~]# dmidecode | more
# dmidecode 2.10
SMBIOS 2.5 present.
27 structures occupying 3569 bytes.
Table at 0x000FB520.
Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
 Vendor: American Megatrends Inc.
 Version: V1.07
 Release Date: 08/21/2009
 Address: 0xF0000
 Runtime Size: 64 kB
 ROM Size: 1024 kB
 Characteristics:
 ISA is supported
 PCI is supported
 PNP is supported
 APM is supported
 BIOS is upgradeable

…and so on and on (press Enter to step through the output line-by-line).

Pretty detailed stuff! It’s basically an entire dump of the information that CPU-Z displays on all of its separate tabs. Is there a way to break this output up into the same sort of separate ‘sections’, so that you only see data on, say, the mainboard, the CPU or the memory modules, as you direct?

Of course there is. Notice that in the output seen so far different parts of it are displayed as DMI Type x …in the above output, it was “DMI Type 0″, for example. Well, you can supply a DMI Type number to the dmidecode program as a run-time parameter, and only that section of the entire output will be displayed.

The bit about which system you own, for example, has DMI Type number 1, so this command:

dmidecode --type 1

…only returns this output:

[root@dirac ~]# dmidecode --type 1
# dmidecode 2.10
SMBIOS 2.5 present.
Handle 0x0001, DMI type 1, 27 bytes
System Information
 Manufacturer: Hewlett-Packard
 Product Name: HP dx2810 MT
 Version: 103C
 Serial Number: xxxxxxxxx
 UUID: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXX
 Wake-up Type: Power Switch
 SKU Number: AB123CD#EFG
 Family: 103C_53307F

The CPU bits and pieces are DMI type 4, so the command dmidecode –type 4 yields just this:

Handle 0x0004, DMI type 4, 40 bytes
Processor Information
 Socket Designation: CPU 1
 Type: Central Processor
 Family: Other
 Manufacturer: Intel
 ID: 7A 06 01 00 FF FB EB BF
 Signature: Type 0, Family 6, Model 23, Stepping 10
 Flags:
 FPU (Floating-point unit on-chip)
 VME (Virtual mode extension)
 DE (Debugging extension)
 PSE (Page size extension)
 TSC (Time stamp counter)
 MSR (Model specific registers)
 PAE (Physical address extension)
 MCE (Machine check exception)
 CX8 (CMPXCHG8 instruction supported)
 APIC (On-chip APIC hardware supported)
 SEP (Fast system call)
 MTRR (Memory type range registers)
 PGE (Page global enable)
 MCA (Machine check architecture)
 CMOV (Conditional move instruction supported)
 PAT (Page attribute table)
 PSE-36 (36-bit page size extension)
 CLFSH (CLFLUSH instruction supported)
 DS (Debug store)
 ACPI (ACPI supported)
 MMX (MMX technology supported)
 FXSR (Fast floating-point save and restore)
 SSE (Streaming SIMD extensions)
 SSE2 (Streaming SIMD extensions 2)
 SS (Self-snoop)
 HTT (Hyper-threading technology)
 TM (Thermal monitor supported)
 PBE (Pending break enabled)
 Version: Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz
 Voltage: 1.2 V
 External Clock: 1333 MHz
 Max Speed: 2666 MHz
 Current Speed: 2666 MHz
 Status: Populated, Enabled
 Upgrade: Other
 L1 Cache Handle: 0x0005
 L2 Cache Handle: 0x0006
 L3 Cache Handle: Not Provided
 Serial Number:
 Asset Tag:
 Part Number:
 Core Count: 4
 Core Enabled: 4
 Thread Count: 4
 Characteristics:
 64-bit capable

Memory details are type 17:

[root@dirac ~]# dmidecode --type 17
# dmidecode 2.10
SMBIOS 2.5 present.
Handle 0x0010, DMI type 17, 27 bytes
Memory Device
 Array Handle: 0x000E
 Error Information Handle: Not Provided
 Total Width: 64 bits
 Data Width: 64 bits
 Size: 2048 MB
 Form Factor: DIMM
 Set: None
 Locator: DIMM0
 Bank Locator: BANK0
 Type: DDR2
 Type Detail: Synchronous
 Speed: 800 MHz
 Manufacturer: CE00000000000000
 Serial Number: SerNum0
 Asset Tag: AssetTagNum0
 Part Number: M3 78T5663QZ3-CF7

And so on an on. The complete list of which DMI type numbers exist and what parts of your system they represent is easily obtainable by checking the man pages for dmidecode (i.e., just type the command man demidecode and scroll down about half-way).

Not something you’ll use every day, I realise (and hence the reason for me committing it to the blog instead of trusting to my memory!), but an excellent and simple utility that saves having to download stuff and worry about installing extras you never intended to have!

A Phoenix?

Posted on by
Reply

There was a time, and not so very many months ago, when it looked as if the CentOS project -producers of a binary clone of Red Hat Enterprise Server- was in technical and social/community disarray.

Red Hat released RHEL 6.0 on 10th November 2010; it took the CentOS developers until 10th July 2011 before they had an equivalent distro available. Red Hat had by then released RHEL 6.1 on 19th May 2011… CentOS achieved a clone of that only on 9th December 2011. There thus appeared to be a systematic technical inability to produce a clone except after a lengthy lag of six months or more.

Over on the social side of things, if someone dared make mention of the fact that the CentOS release dates were lagging the RHEL originals, with no transparency regarding progress or process, they generally got shouted at for their temerity. Not to mention little disasters like the lead developer going missing with the keys to the kingdom.

Meanwhile, Scientific Linux -another clone of Red Hat, this time produced by a small team of developers at places like CERN and Fermilab- appeared to be having no such technical or social problems, managing a 6.0 release on 3rd March 2011 (so, about 3.5 months after Red Hat’s original and four months ahead of CentOS), and a 6.1 on 28th July 2011 (2 months after Red Hat, 5 months ahead of CentOS).

Given these timelines, I don’t think it was much of a surprise that many people appeared to switch away from CentOS to Scientific Linux. I did myself, anyway -and am happily running a bunch of file servers, Oracle boxes, laptops, netbooks and my main desktop PC on SL6.1 as a result.

However, I was pleased (and a bit surprised, to be honest) to note that the CentOS team appear to have sorted out their technical issues, managing to produce a clone of Red Hat’s 6.2 release on December 20th, just two weeks after Red Hat released the original. That is one of their best ‘lag efforts’ since they were producing clones of version 4.x back around 2007. If it is indicative of a generally more capable, streamlined and efficient cloning operation that can achieve similarly effective results as future RHEL releases are made, I for one shall be very happy. And now the developers seem to have mastered the technical arts of cloning RHEL 6+, maybe they’ll become a little less defensive and much more transparent about the whole development process in the future. Fingers crossed, anyway.

As to the new distro itself… well, not really much to report there if visual bling is your thing: all the changes from 6.1 are under-the-hood things which may or may not make much difference to you, depending on the way you specifically use the OS. The introduction of asynchronous writes for CIFS (i.e., Samba shares), thereby improving the performance of network shares by maybe 200%, is pretty significant if you have Windows machines on your network, for example, but is not a new feature that is likely to set the world on fire otherwise. Loads of other such techie changes are listed in Red Hat’s original release notes. The bottom line, however, is that if you are happily running Scientific Linux 6.1, you aren’t missing out on anything particularly major as you wait for the Scientific 6.2 release (probably due in around March or April this year).

Anyway, it’s good to see the CentOS project apparently back in business in earnest, and hopefully it will stay that way for a long time to come. Personally, I’ll be sticking with Scientific Linux for a good while yet: it’s a more placid and predictable experience, I think! But it’s nice to know there are viable alternatives out there.

Oh, and incidentally, the Gladstone Oracle Preinstaller has been updated to work with the new Centos release.

Win NFS Fixed (at a cost)

Posted on by
Reply

Further to my last post, in which it was discovered that the NFS client tool included in some editions of Windows 7 can’t cope with accented characters (or anything not in the standard American view of the alphabet, really)…

The good news is that I have a fix. The bad news is that it comes in the form of a commercial NFS client, called ProNFS, which costs US$40. That’s at least $15 more than I feel entirely comfortable paying, but there’s a 30-day trialware edition that at least you can test stuff out with before you part with your hard-earned moolah.

Crucially, in the client settings tool that is provided as part of the ProNFS software stack, there’s this little dialog box:

Spot the reference to using UTF8 file names! Woot!

Once you then use the ‘map drive’ tool to find your NFS shares and mount them as a standard windows drive letter affair, everything works as advertised on the tin-lid:

Spot all those European names displaying correctly, replete with accents, umlauts and cedillas! Problem solved, I think.

I do have a few “issues” with this approach to solving the problem, though. I suppose the first one is simply this: “if they can do it, why can’t you, Microsoft?!”. The second is that the installer for this program looks like it was written in 1994 and hasn’t been updated since! There are lots of little touches on the company’s website, for example, that make me nervous -constant references to the software being compatible with Vista, for example, with never a mention of Windows 7. If you check out their promotional screenshot, too, it will seem as if the software hasn’t been updated since 2003! They’re shooting themselves in the foot there, because if you actually run the NFS server component today, it will report version 1.6 with a compile date of June 23rd 2011, which is much more reassuring! Finally, there’s the not-so-minor matter of the Blue Screen of Death I got when I removed the evaluation version and performed post-removal reboot. I haven’t seen one of those for years, so getting one as the software is removed didn’t fill me with warm glows and kindly feelings!

In the end, though, such things are probably not major issues. I should say in fairness that once the software was installed and running, it behaved itself perfectly -and I can live with slightly out-of-date documentation and promotional wares so long as the software behaves itself. Yes, I could wish it were a tad cheaper, but even at US$40, if it means I don’t have to configure Samba, it’s probably just about worth it! Colour me happy, ish.

NFS, Windows and Foreign Characters

Posted on by
1

The house now only has one Windows PC left (running 64-bit Windows 7). Everything else is running Linux -though one netbook still retains dual boot capability, just in case. (In case of what exactly I’m not quite sure, but it always pays to be prepared, I guess). The question now arises, then: how best to get that one Windows PC accessing files from the file server (which is busy running Scientific Linux 6.1)?

The obvious answer is ‘Samba’: a quick fiddle on the file server to install the requisite Samba server packages, a modest amount of editing smb.conf and (usually) all is set and ready to run.

This time, however, I thought I’d be a bit more adventurous. Every other Server, PC, laptop or netbook is running Linux, so why impose the overhead of Samba if it’s not needed for most of the machines on my network? Why not get Linux’s “native” file sharing system (NFS, or Network File System) running instead and get the Windows PC hooking into that?

Well, the NFS bit is indeed incredibly easy to set up. It’s already installed on the server: all I had to do was make sure the firewall allowed traffic through (on ports 111 and 2049), configure an export file and start the relevant service. All done in about 5 minutes, to be honest -which is a lot faster than Samba usually is for me! The export file (/etc/exports) couldn’t be much simpler, either, for it contains just one line:

/safedata 192.168.0.0/24(rw,sync)

The safedata directory is the mount point for my RAID 5 array, so has all the important data on it. I’m just saying here that anyone on my home network is allowed to get read-write access to it (in principle, anyway… normal file permissions still apply, so unless I’ve chmodded everything 777, not everything will be writeable).

The Linux clients are a doddle to configure, too: it’s simply a matter of typing this sort of thing (as root):

mount 192.168.0.100:/safedata /nfsmounts

That just says ‘find the “safedata” export on the file server and mount it at the /nfsmounts mount point’. And, just as I had hoped, I found large files could be copied across to the server from my desktop at a rate of about 48MB/sec. That’s 384 megabits per second, which isn’t bad for my rather humdrum gigabit Ethernet link -and a lot faster than the consistent 25MB/sec I used to get on exactly the same hardware when using Samba to do Linux-to-Linux transfers.

So NFS it is, then!

Not so fast! There’s the not-so-minor matter of configuring The Other Half’s Windows PC to partake in this feast of NFS-ness. As I mentioned, that’s running Windows 7… and it’s the Ultimate edition, which means an NFS client is readily available. All you have to do is go to Start > Control Panel > Programs and then select the Turn Windows features on or off option:

You simply find the Services for NFS item, expand it and select the two sub-options for activation. Once you’ve done that, you can then issue ‘mount’ commands on Windows that resemble their Linux cousins very closely:

The basic format of the command is simply mount server:/share/name drive_letter: …and in my case, it means my Music folder stored on the server’s RAID array is now accessible from the Windows PC by navigating to the M: drive in Explorer:

And this is the point where the good news abruptly ends. Sure, getting the NFS export seen and mounted by the Windows PC is a piece of cake… but as any fule kno, André Mathieu’s name is spelled with an ‘e-acute’ at the end of his first name, not a capital-A-plus-Copyright-symbol as Windows Explorer seems to think is appropriate. Arnold Schönberg will also be missing his O-umlaut and wouldn’t be impressed with his newly-acquired A-with-tilde-plus-paragraph-mark.

Of course, what we have here is ye olde and ancient trouble with extended Western European ‘foreign’ characters. It’s bugged me for years when doing Samba mounts (but is easily fixed there by specifying a utf-8 mount option when issuing the mount command). Now it’s back with a vengeance… and there’s nothing I can do (apparently) to fix it!

Here’s the real problem, from the Windows perspective:

The mount command on its own lists network drives which have been mounted and the options/attributes that apply to those mounts. The killer line here is lang=ANSI, indicating that Windows has mounted the network drive assuming that it will find only ANSI characters at the other end. When it then actually finds UTF-8 characters instead, it gets itself very confused, as we’ve seen.

Knowing this, it’s easy to speculate that there must be a way of specifying something like lang=utf8 when performing the original mount command and that this would fix the problem:

That’s me first unmounting the M: drive I’d created before and then attempting to re-mount it but with a utf8 language specified instead of the default ansi one. As you can see, however, “utf8″ is not an option that’s actually available for this parameter. You can certainly choose a variety of Chinese, Korean and Japanese character sets -and, of course, “ansi” is valid, but not “utf-8″ or anything like it.

As far as I could tell from reading the documentation that comes with the Windows 7 NFS client (go to Control Panel > System and Security > Administrative Tools then open the Services for Network File System (NFS) program and hit [F1]), there are no other mount options that can be specified which would have anything to do with getting the character set right. So, as best as I can tell, there is no fix for this problem… which is truly dumb!

Just to emphasize how silly this is, here’s the exact same Windows PC browsing through the exact same folders on the exact same server …only this time, using Samba:

The two Andrés have their acute accents, and Arnold gets his umlaut back… no problems at all.

For me, unless someone else points me in the direction of a fix, this simply means it’s back to Samba and boo-hiss to NFS, which is a shame as I would much prefer things the other way round.

There are, apparently, commercial NFS clients for Windows. I may have to try to evaluate one of those to see if the character set issues are surmountable, but I am not holding my breath. In the meantime, the freebie stuff from Microsoft on this score is functionally useless to me :-(

Is this thing on??

Posted on by
Reply

Silly, trivial little thing, I realise, but how do you know if your network interface on a Linux box is running at its intended 1000Mbps or at something a lot slower (like 100Mbps)? You can always look at the network switch you’ve connected to, of course, and see whether it’s glowing green (1000) or yellow (100)… but different connection speeds resulting in different connection colours might not be a feature of the particular switch you use. And even if it is, how do you know that Linux is convinced it’s able to run at the Gigabit speed?

On Scientific Linux 6.1, just type this command as root:

ethtool eth0

The “eth0″ bit is your network interface identifier -if you’ve multiple network interfaces, it may well need to be changed to ‘eth1′ or something else entirely. Assuming you get the interface name correct, though, you should see quite a lot of information about the inner workings of that interface …including a line that reads Speed: 1000Mb/s

Of course, it may read just 100Mb/s, or something even worse. But at least you now know!

The ethtool utility is a standard part of a Scientific Linux desktop: I certainly didn’t have to install any additional packages to get it. It can be used to set fairly esoteric networking attributes, not just check what they’re already set to. It’s quite a handy little utility, in short, and is fully documented here, amongst other places.

Stellarium on Scientific Linux 6.1

Posted on by
5

I have updated my recent article on how to configure Scientific Linux 6.1 to be your desktop operating system in one crucial respect: the original instructions on how to install Stellarium (the world’s best astronomy program bar none) didn’t work properly.

The original instructions were to add the repoforge repository to the list of available respositories and then simply do a yum install stellarium.

This technique is very convenient and appears to work -but, unfortunately, it installs version 10.2 of Stellarium …which has a known bug whereby its display is garbled when using recent NVidia graphics drivers (I have no idea if ATI or Intel drivers are similarly a problem, but from my reading it appears they might be). You end up with this nonsense when you run the program:

Note the garbled text menus, the complete lack of stars in the main part of the window and the ‘fuzzy’ display of the various toolbars. The solution is, I’m afraid, to uninstall the version of Stellarium that comes from the repositories and, instead, to download source code and compile it. Normally, I’d run a mile from self-compilation, but in this case it is (a) necessary and (b) simple. It also, not incidentally, (c) results in a fully working version of Stellarium. The details are as follows (do all the following as root):

yum remove stellarium

(which cleans out any existing Stellarium installation). Then: Download the source code from http://sourceforge.net/projects/stellarium/files/Stellarium-sources/0.11.1/stellarium-0.11.1.tar.gz/download, saving it to (say) your Desktop directory. Next, right-click the downloaded tarball and select the Extract Here menu option. That will create a directory called something like /home/hjr/Desktop/stellarium-11.1. Change to that directory and create a couple of new sub-directories, as follows:

cd stellarium-11.1
mkdir -p builds/unix
cd builds/unix

Again as root, and at a command prompt, type the following commands:

yum install gcc gcc-c++ libstdc++ cmake cmake-gui gettext gettext-devel mesa-libGL-devel mesa-libGLU-devel zlib-devel libpng-devel freetype-devel boost-devel libjpeg-devel qt-devel doxygen graphviz subversion make

That gets the software dependencies installed. Then you can (again as root) issue three simple commands:

cmake ../..
make
make install

Note that the cmake command is issued whilst you’re sitting in your stellarium-11.1/builds/unix directory. Hence the use of ‘..’ to reference other directories, relative to that.

Now you have the latest version of Stellarium installed and can (as yourself) simply type the command stellarium to launch the thing. This time, it should all work as expected:

You’ll probably want to create a new launcher for the program on your top panel because the self-compile route doesn’t create nice menu options to launch the program. If you’d like to edit the Applications menu and add an item that points to your freshly-installed application, you’ll need to install alacarte (easily done with a simple yum install alacarte). In either case, you’ll end up configuring an application launcher to simply run the command stellarium.