OpenSuSe useradd help
or why developers should not add nonsense options
This weekend I had to do some things on an OpenSuSe 10.3 server (some dirty migration of a Zope/PostgreSQL webapp). One of the tasks I had to do involved the creation of some user accounts. Yes, I know there is YasT in the SuSe world, but something like the Slackware's adduser script should be a better tool.
In OpenSuSe, there is a man page for adduser but calling man adduser sends you to useradd(8)... ok, (I thought), "useradd should be a similar tool".
So I tried useradd directly, expecting a help message:
server:~ # useradd
useradd: Too few arguments.
Try `useradd --help' or `useradd --usage' for more information.
Nice, there was a message, and it pointed me to two different options to get more info. I decided to try --usage (the tipical shorter version of the help) but, guess what?
server:~ # useradd --usage
Usage: useradd ...
WTF! That is a really useful message! (of course --help has the full help, but anyway...)
Restoring your Desktop folder in Ubuntu
This is useful if you've lost your desktop folder in ubuntu due to some Filesystem crash
This morning one of the Ubuntu workstations at work began to perform incredibly bad. It seems there was some kind of problem with the workstation and the user that works everyday with it just rebooted the machine (everybody know a reboot is the solution to all the problems you could find in a computer... ains...).
After the reboot, she found that the desktop wallpaper and all the icons were gone. She came to me and asked me if I could take a look and I did.
After some tests and a lot of log parsing (thnk god Ubuntu developers didn't get rid of /var/log/* yet) I found that there was a problem with the ext3 filesystem, and some inodes were deleted during the reboot (urgh!). It seems those inodes were related to the contents in the Desktop folder (where all the desktop items are stored). When she started a new gnome session, the system picked up a folder called Desktop within another folder in the user's home directory (Why? I've no idea... and I don't know why a folder called Desktop was in there.). Then I moved the Desktop folder to $HOME and restarted the gnome session (hey, it seemed like a reasonable solution to me) just to find out that the system was then using the whole home folder as the desktop (and all the contents in the home folder were spread all over the screen).
After some more digging, I tried removing all the .gnome2, .gconf, .gconfd, .nautilus, etc config files and directories and I checked that, in the gconf editor, nautilus had not activated the "Use your home folder as the desktop folder" option. Nothing worked.
But, in the end, I found ~/.config/user-dirs.dirs. It seems to be Ununtu-specific and it is a file where you can set not only your desktop folder, but your pictures/movie/public/etc folders (those you would find in your home after your first login in a Ubuntu workstation). The contents of that file were:
# This file is written by xdg-user-dirs-update
# If you want to change or add directories, just edit the line you're
# interested in. All local changes will be retained on the next run
# Format is XDG_xxx_DIR="$HOME/yyy", where yyy is a shell-escaped
# homedir-relative path, or XDG_xxx_DIR="/yyy", where /yyy is an
# absolute path. No other format is supported.
So, I only had to change it a little bit:
To get it working properly again (after logging out and logging in again in the gnome session).
Repair a damaged XFS filesystem within a LVM2 setup
This could be a little bit tricky, and you should have a Slax Live CD at hand
Today one of the Debian workstations at work started to do some strange things, and those things helped us finding a problem with the XFS filesystem mounted on /.
If I tried to delete some files located in such partition I got a message complaining about some problems in the filesystem hierarchy that should be fixed before proceeding.
This machine has the usual LVM2 setup, being one of the logical volumes the partition that contains the data mounted under the / mount point.
You can't check/repair a XFS filesystem when you have such filesystem mounted, so first I tried to boot Debian into single user mode, but (sincerely, I still don't know why) it kept itself mounting the root partition as read-write (rw) even if I tried to force it to mount it read-only (ro). So I got tired about it (I don't like Debian at all anyway) and I just got a Slax LiveCD, put it in the CD unit and started the computer with it.
In the boot menu (where you have multiple options for booting the Slax system) I selected Slax Text mode, because I don't need all the X-stuff to check some partitions.
Once it finished booting up, I got the usual login screen from Slax, something like this:
I logged in as root and I checked that Slax had recognized the hard drive (/dev/sda in my case). I was able to see two partitions for the drive:
brw-rw---- 1 root disk 8, 0 sep 23 12:20 /dev/sda
brw-rw---- 1 root disk 8, 1 sep 23 12:20 /dev/sda1
brw-rw---- 1 root disk 8, 2 sep 23 12:20 /dev/sda2
sda1 is an ext2 partition outside the LVM (mounted as /boot) and sda2 is the partition containing the LVM.
So... so far I had the drive and the phisical partitions recognized, but I couldn't check the root partition yet, I needed access to the LVM logical volumes.
One of the good things about Slax is that it comes with LVM/LVM2 support out of the box, so I just used some tools to get the job done.
First I used vgscan to search for LVM information in all the available hard drives:
vgscan -v --mknodes
The --mknodes parameter tells vgscan to create all the needed entries in /dev so you can use the LVM stuff.
It recognized the LVM information and created all the needed entries under /dev/mapper. The one that interested me the most was /dev/mapper/japones-root (in my case, in yours it will depend on the name you gave the volume) because that was the logical volume mounted as the root partition.
Ok, now I've found the LVM volumes, I needed to activate them, which could be done using vgchange:
vgchange -a y
With that, I did activate all the logical volumes found.
Finally, I used the xfs_check and xfs_repair tools to perform all the needed tasks in the XFS filesystem and repair it:
I found that the filesystem was quite corrupt and _xfs_repair had to do a lot of work on some parts of it, but the system worked just fine after rebooting back into Debian.
Once the _xfs_repair tool finished cleaning the filesystem I mounted it (to see if everything was working fine):
mkdir /mnt/japones && mount /dev/mapper/japones-root /mnt/japones
And after checking everything was ok I just rebooted the machine, removed the Slax CD and tried Debian again.
Everything worked fine.