Automatic Portland

Posted on February 21, 2012 by dizwell

Ah, automation! Where would we be without it? (It is a little-known fact that the total mileage of railway line in England did not exceed the total mileage of canals in England until 1861 -some 80 years later than is commonly supposed, and proof that the Industrial Revolution never really happened -except in Germany, funnily enough. Britain, though, had an Industrial Evolution).

Anyway, I digress. Automation is good, and it helps produce nicely-standardized things which are therefore more predictable and more stable than their chaotic hand-built equivalents.

This goes for operating system installs, too.

Having got Gladstone doing his thing to hand-built servers, ensuring a level playing field when it comes time to install Oracle; having then got Palmerston working overtime to do the same thing for a Kickstart-automated server build; it is now time for me to introduce Portland: the script you run to standardize and automate your RCSL builds when you don’t want to install Oracle.

Perhaps being a little more positive, I should say that Portland is the script to run when you want the Gimp, VLC, Eclipse, Java, Apache Directory Studio, Opera, Rhythmbox, Handbrake …and all those other good productivity programs (like Solitaire and Chess)… added to an otherwise standard and minimal RCSL server installation. Preferably without all the hassle and confusion that the bazillion-and-one ‘how to do a perfect desktop’ articles out there seem to want to inflict on you!

Portland turns RCSL servers into usable desktops, in other words (including switching from OpenOffice to LibreOffice).

I particularly like it because it makes continued and almost-exclusive reference to mirror.aarnet.edu.au (and, indeed, changes the standard yum repositories so that they point there too). That mirror happens to be (a) close to Australians and (b) completely unmetered in use for us poor Telstra ~~customers~~ shmucks. For me, it means I can install RCSL servers until the cows come home without running up huge ISP bills or excess download consequences. For others, it will be a disaster, of course, since it will be using perhaps the remotest, non-free repositories in (their) existence. I’ll work on that for a future update! Meanwhile, you could do a global search-and-replace of the mirror URL before running it.

So, to sum up:

You use the Kickstart Configurator to specify a new non-Oracle server’s details.
The last line of the resulting Kickstart script will cause a portland.sh script to be downloaded to the new server’s root directory.
When your over-the-internal-network ‘base build’ is complete, and provided you have a functioning Internet connection, you log on as root and invoke that script (a simple sh /portland.sh will do it).
20 minutes later, your server build will complete. including a nice set of top-panel application launchers for all the apps I consider to be vital (you might disagree with my choice of launchers, but that’s life!)
There are two interactive prompts throughout the entire process: Dropbox asks you if it’s OK to close all Nautilus windows (the answer is ‘yes’), and Calibre says it’s going to install to /opt (press Enter to accept). If I can get those two working in a non-interactive mode, I will.

There are still a couple of things I definitely won’t automate, the most significant of which is the installation of proprietary graphics drivers: I can’t find a reliable way of working out what graphics card is installed in a PC, so can’t automate the installation of the right binary blob. Install the wrong one, however, and the PC may well refuse to display anything at its next reboot. I’ve therefore decided to leave well alone for now!

But for the most part, I can now roll out a bundle of RCSL servers in double-quick time and have them all look as I want them to, without really having to do anything. And that’s the sort of automation I can live with!

Footnote 1: because I know literally tens of thousands of people will be asking, William Henry Cavendish-Bentinck was the 3rd Duke of Portland and served as British Prime Minister twice (in 1783 and 1807-1809, which is the longest gap between ‘turns’ of any British Prime Minister. If Margaret Thatcher wanted to achieve the same thing, she’d be making a fresh run for office right about now). The Portland Vase (see left, being peered at in the British Museum by yours truly, circa 2010) gets its name from the Duke’s family, since his mother bought it from the British Ambassador in Naples. Don’t ask how he came to be selling in the first place, though!

Footnote 2: Portland installs an, er, “eclectic” mix of software that suits my needs -which may not suit everyone or anyone else’s. I’ll take comments/suggestions on what ought/ought not to get included, if it helps make the script as a whole more useful. Suggestions need to be in the repositories (and thus a yum install away), or easily obtainable with wget (which rules out Oracle and VMware Workstation, for example).

Footnote 3: The Kickstart Configurator has been modified a little so that it now automatically downloads the portland.sh shell script (to the / directory) if you select to create a non-Oracle configuration. Whether you choose to run it after that is up to you, of course, but at least it will be there. If you tell the Configurator you’re building an Oracle server, of course, then its behaviour is unchanged: it automatically downloads the palmerston.sh shell script instead (from your own Kickstart server).

Footnote 4: The complete list of packages/applications Portland installs currently is as follows:
alacarte, alltray, ApacheDirectoryStudio-linux-x86_64-2.0.0, brasero, calibre-ebook reader, cheese, cuetools, dia, dropbox-0.7.1-1, dvd95, dvdbackup, easytag, eclipse, ekiga, evolution, gftp, gimp, gnome-games, gnome-games-extra, gnote, gstreamer-plugins-ugly, gthumb, guake, handbrake-gui-0.9.5-1, hardinfo, keepassx-0.4.3-1, libdvdcss, libreoffice 3.5.0, mencoder, mozilla-vlc, ntfs-3g, openjava, opera-11.61, pidgin, rhythmbox, rlwrap, shntool, sound-juicer, soundconverter, stellarium, thunderbird, transcode, transmission, tsclient, VirtualBox, xsane

Watch your bits!

Posted on February 20, 2012 by dizwell

This is what happens when you start up a server with a Scientific Linux 6.2 32-bit netinstall disk and expect it to be able to continue with a 64-bit network installation:

The clue is buried in the error text: Exec format error means “you’re trying to execute a 64-bit executable when I was expecting 32-bit ones, so that format/bit-architecture is wrong”.

The references to “anaconda failed” and “backtracing /lib/lib.s.6″ are just red herrings, really, potentially diverting your attention from the real issue: You can’t mix your architectures. If your Kickstart Server is dishing up 64-bit distros, you need to boot with a 64-bit netinstall boot disk. Obvious, really, but I’d never accidentally mixed-and-matched before, so I never quite knew what to expect.

Now I do!

New Science…

Posted on February 19, 2012 by dizwell

Am happy to report that Scientific Linux 6.2 is properly and finally out, thus completing the ‘set’ of RHEL 6.2-compatible freebie distros. (Centos 6.2 was released just before Christmas).

As a content user of the Scientific Linux 6.1 release on my desktop since around the start of December 2011, the new release means either I have to sit there pretending I don’t care about having the latest and greatest, or I can just upgrade and be done with it. I rather suspect the latter will be the course I take!

Not that there’s a huge difference between the versions, of course.

Anyway, the relevant ISOs are available here -and my Kickstart Configurator and associated articles will be updated soon accordingly.

Look Ma! No network…

Posted on February 14, 2012 by dizwell

I was installing some servers in Seattle recently, when I was informed that it was not company policy to allow their servers to have Internet access, of any sort, ever. This was a bit of a blow for me, because my Gladstone script (which I use to configure production Red Hat boxes as Oracle database servers) relies on being able to do various “yum install …” commands to get the software prerequisites correct.

It was irritating, though quite understandable -and we worked around the issue by giving me temporary access to the Internet, swiftly revoked once the installs were complete. But the incident made me realise that Gladstone’s reliance on Internet connectivity was misguided.

In fact, it’s never been strictly necessary for Gladstone to have Internet access at all: every one of the software prerequisites are available on the DVD installation media for RCSL distros, so it’s always been possible to install entirely from locally-available media. I used the ‘yum install’ method simply because it was easier: for one thing, it ensured all software dependencies were satisfied automatically.

Well, I have now resolved that particular issue.

My new Kickstart Configurator tool will now output a kickstart file which will perform a completely local installation (i.e., no Internet downloads) that nevertheless satisfies all Oracle software prerequisites. Of course, there’s still the Palmerston script which needs to be downloaded and run to finish things off in an interactive fashion, but if you download that ahead of time and store it on your Kickstart server, you can transfer that internally, still without recourse to the wider Internet.

Kickstart + Palmerston… perfect results every time, and not an external network in sight. My man in Seattle would be happier, I think!

Did I mention Palmerston?

Posted on February 8, 2012 by dizwell

I have just released a new article explaining how to set up a Kickstart server as a way of achieving speedy, reliable and standardised RCSL server installations.

In some ways, it’s just a rather more Kickstart-focussed version of my existing ‘how to build an Apache web server’ piece.

However, it’s a little bit more than that, because it introduces two things:

The Dixnix Kickstart Configurator; and
Palmerston (the post-Gladstone shell script)

The Kickstart Configurator is just a little something I threw together to avoid the tedium of having to remember to alter the network details in a Kickstart file before re-using it. It will additionally do most of the Oracle prerequisites for you, if you ask it to.

Palmerston is simply a version of my Gladstone Oracle pre-installation script that omits the downloading/installing of software packages… because the Kickstart configuration script generated by the Configurator will have already handled all software prerequisites for you, if you asked it to. It also ditches all support for non RCSL distros, because only an RCSL user will ever be invoking it (everyone else will still be invoking Gladstone).

Together, they make building RCSL servers in general and Oracle servers in particular just that little bit easier. (Well, they do for me, anyway!)

Minimising Evolution

Posted on January 27, 2012 by dizwell

You want to run Evolution as your email client, but you then notice it doesn’t have a ‘keep running, but minimized in the system tray, so it can keep checking for new email periodically without cluttering up my taskbar’ option.

The official line on this seems to be that this is an insane requirement and that to satisfy it would count as “abuse” of the perfect Gnome environment… but that’s just typical arrogant bluster from the Gnome and/or Evolution developers. However, because it’s the official line, there really is no native, built-in way to do this very simple deed.

Here’s one possible solution, however, which I found met my requirements without necessitating that I take a degree in advanced physics to make it happen.

Download AllTray
Right-click the tarball and extract
As root, go the the alltray-0.70 directory and issue three commands, in sequence:

./configure
make
make install

Alter the launcher for Evolution (on the top panel, for example) so that instead of just triggering the command “evolution” it now triggers the command “alltray evolution”.

When you now launch Evolution with that quicklaunch icon, the program will immediately minimize itself to the system tray. An envelope icon will appear there. Click it once to make Evolution appear full-screen, once more to re-minimize (or, click close). To genuinely close the program, right-click the envelope icon and click Exit. Evolution will momentarily appear full-screen before closing itself.

OpenAaarghDAP!

Posted on January 23, 2012 by dizwell

If there is a ghastlier bit of technology than LDAP, I don’t know what it is. The very name is redolent of nerds laughing at you: Lightweight Directory Access Protocol? Lightweight??! Very funny, guys!

There’s nothing really lightweight about it, of course. It’s a mostly-incomprehensible melange of apparently bizarre syntax and a propensity to throw a wobbly at the slightest mis-placed comma or out-of-position double quote. What’s more, it’s documentation sucks and it’s difficult even to find anyone explaining why you might want to do battle with it in the first place.

And the cause of the ‘Aaaargh!’ in this blog’s title is that it gets even better: the entire methodology, structure, call it what-you-will of the OpenLDAP implementation of LDAP changed between Red Hat Enterprise Linux 5.x and 6.x. In the old days, we configured a slapd.conf configuration file; these days, you are now supposed to poke around inside a directory called, fetchingly, /slapd.d/cn=schema. Yup, they stuck an equals sign in the directory name. Just wait until you have to edit such catchy files as olcDatabase={0}config.ldif or olcDatabase={-1}frontend.ldif. I mean, what were they on when they came up with those filenames??!

What little documentation you may find on the old slapd.conf way of doing things is mostly meaningless in this brave new world of RHEL6-style madness. So back to square one, then… which is to say, fumbling around in the dark in the hope you’ll get lucky.

Ordinarily, at this point I’d give up, consigning the whole thing to the too-hard basket. But there is actually a good reason to do battle with OpenLDAP: it makes for a free (and ultimately relatively simple) way of doing centralized TNS names resolution for Oracle databases.

Of course, the official way of doing that is to use Oracle’s own Oracle Internet Directory (OID) -and I did actually write an article about setting that up way back in about 2006. But there are lots of problems with OID. It’s a tiny part of the gigantic ‘Oracle Identity Management’ infrastructure for one thing: I defy anyone who isn’t religiously following some documentation to go to www.oracle.com and download the correct bit of OIM in order to just get the names resolution stuff working! For another thing, I never did get OID working on any version of Red Hat EL later than 4.7. I don’t know if that’s changed (I presume it has), but it was a bit of a show-stopper at the time, that’s for sure! Dare I mention at this point that RHEL 4.7 is to reach its end-of-life on February 29th 2012… er, in approximately 6 weeks, in other words?

I suppose I might also throw in the fact that I would prefer ‘completely and definitely free’ to ‘possibly, but probably not, but just maybe comes with licensing issues that are associated with a price tag’.

All of which is by way of explaining why I decided to (a) get OpenLDAP running on RHEL 5.x and 6.x -and then (b) get OID functionality working with it in both configurations. I then decided to throw in (c): a nice GUI way of working with the LDAP monster.

The OpenLDAP-as-OID-Replacement article is therefore now available.

Kickstart and DHCP

Posted on January 18, 2012 by dizwell

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 January 16, 2012 by dizwell

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 January 13, 2012 by dizwell

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!

Diznix Blog

News from Nowhere

Category Archives: Linux