I've just spent a good few hours trying to find any clues to the problem I was getting. du command would fail with a mysterious "fts_read" error, and there didn't seem to be any good answers on the net with explanations why. I figured someday this post will be found and might save someone a lot of time. It's a lengthy post and I believe the first one on this blog to be truly "advanced" in a technical sense.
I've been upgrading Ubuntu installations quite a few times recently, and thought it makes sense to post a really short how-to if you ever want to upgrade your Ubuntu distro from the command line.
Use apt-get to upgrade Ubuntu
The procedure for upgrading one Ubuntu release to another one is pretty straightforward. There are some rules though:
- Never attempt to skip a release or two when upgrading
- Never do a few Ubuntu release upgrades in a row without reboots in between
- Always backup the files you change
- Always have an install CD for your current Ubuntu release around
I know I've spoken about timestamps already, but I'd like to further expand the topic.
While there's a great GNU stat command in Linux systems, there's no such thing in Solaris by default, and so you usually depend on ls command with various options to look at file's creation, modification or access time.
The standard /bin/ls command in Solaris doesn't always show you the full timpestamp, usually if it's about a time too far in the past or a bit into the future – so today I'm going to show you a trick to work around it and still confirm such timestamps for any file.
Yesterday in my post on numeric userids instead of usernames, I touched briefly the problem of recovering the username if you only know the userid it once had. Today I would like to show you another option which may be available to you when it comes to recovering the usernames of removed users by their userid.
As you know, every file in your Unix OS belongs to some user and some group. It is very easy to confirm the ownership of any file because user id and group id which own the file are always linked to the file. However, sometimes you can't tell which user owns the file, and today I'm going to explain why. It's a rather lengthy post and a complicated matter, so please leave questions or comments to help me polish this article off.
Files and directories ownership in Unix
If you look at any file using ls command, you will see an output like the one shown below – it reveals file access permissions, user and group id of the owner, the modification timestamp and the file name itself:
ubuntu$ ls -l /tmp/myfile -rw-r--r-- 1 greys admin 0 Jan 6 03:51 /tmp/myfile
Many software products, especially the commercial ones, are distributed as 32-bit packages. This means that they won't be installed on your 64-bit system unless you clearly specify that you want to override the architecture dependency.
If you're using Ubuntu or any other Debian based distribution, this post will teach you how to install 32-bit deb packages on your 64-bit OS.
Is it possible to run 32-bit applications on 64-bit OS?
In Unix world, yes: it is quite possible to run 32-bit binaries on 64-bit OS. There should generally be no problem, but there are, as always, a few caveats:
You probably know that modern Linux distributions have many things in common. Well, one of the reasons for this is LSB – Linux Standard Base. LSB is a joint project by a number of Linux vendors to standardize the OS environment.
The goal of the LSB is to develop and promote a set of standards that will increase compatibility among Linux distributions and enable software applications to run on any compliant system. In addition, the LSB will help coordinate efforts to recruit software vendors to port and write products for Linux.
One of the immediate benefits of LSB compliancy is ability to confirm the exact information about your Linux release using the lsb_release command. By exact information I mean the release version, vendor name and most interestingly the codename of your current Linux release.
I've noticed how many people found other pages of this blog trying to find more information about Unix sockets, and so I thought it's about time we shed some light on this seeming mysterious, but really simple concept.
What is a Unix socket?
A Unix socket (the technically correct name for it is Unix domain socket, UDS) is a way of inter-process communication (IPC) in Unix. Like almost everything in Unix, a socket is a file. It's a special file, to be precise. Unix processes which want to communicate between each other use special set of functions to access the special file of a Unix socket, and easily exchange data in both directions.
In very simple terms, a Unix socket is nothing but a byte stream – a data transfer between processes running locally or on networked Unix systems.
This is a very brief introduction into navigating the device paths in Solaris. I'm using a Solaris 10 installed on Sun v490 for all the commands shown below.
Device files in Solaris
Even though all the block and character special device files are traditionally found under /dev directory, if you look closer at your Solaris 10 setup you will notice that they're not the device files themselves, but instead are just symbolic links to device files under /devices directory.
Solaris uses /devices directory for representing all the physical hierarchy of installed devices and buses found on your hardware system.
I've recently upgraded Apache and PHP on my VPS, and one of the unpleasant surprises was that some scripts which tried including pages from remote sites (I know, not the most secure approach, but there were reasons for that) got broken.
Traditionally, all the websites Google finds suggest that you double-check that your php.ini config has the allow_url_fopen enabled:
allow_url_fopen = On