Duplicity fails on 3GB /tmp

ript>

Backup application Duplicity has just filled up my /tmp, located on / partition with 3GB free space, during verification of a full backup and, finally, reported ‘failure’!
After quitting Duplicity, I have 1GB less free space on my / partition.

I wonder how much bigger the /tmp space need to be…

—-

Update [2013/11/19]:

I’ve found the ‘lost’ GB into ~/.cache/deja-dup directory [naturally] (or /root/.cache/deja-dup if it runs under gksudo), but I still don’t know why 3 GB of temporary space are not enough.


Visit The Light of the LAMP blog for more…

Think like a virus!

Not related to L.A.M.P. technologies, but a useful quote to remember if you are a net admin:

As a network administrator, you have to think like a virus.
How can I get into a network?
Which points are the most vulnerable?
Once in, what’s the easiest path to destruction?

From the “Windows sources” magazine, July 1997 issue, page 158, “NT admin> Stop network attacks” by David Chernicoff


Visit The Light of the LAMP blog for more…

send mail to correct local host

After upgrading my previous server with a new one, I run a lot of migration scripts and update procedures to make sure that everything transferred OK and worked as expected. However, a little thing kept bugging me until today.

Usually, when you want to send an email message to a local user, you either send it to user@localhost or just to user and the mail service makes sure that the local hostname is added after the ‘@’ (if there is nothing there of course). But the problem for me was that messages to local users relayed through my external mailgate after the upgrade.

The /etc/hosts and the configuration files of postfix were already filled with the correct hostnames and I could not find anything until I tried to search all the files in /etc hierarchy for the old hostname.

To my surprise, I found that the old hostname was still in /etc/mailname which, according to its man page, is a plain ASCII configuration file, which on a Debian system contains the visible mail name of the system.

I don’t know if the upgrade kept it intact or it was the restoration of /etc data files that caused this discrepancy. The good thing is that I found it easily by searching with grep.


Visit The Light of the LAMP blog for more…

Always check your fingers while being root

Yesterday, while I was reading some very old magazine articles, I remembered a “horror” story that happened to me a long time ago, when I was learning to administer my first Sun Solaris system. It goes like this…

I was following the instructions to install some new application and I had to add a new user in /etc/passwd file. I kept a backup copy and I started editing it with vi. What I didn’t knew at that time, was that cursor (arrow) keys were not used for moving the cursor and they produced “~” instead. OK, I thought, back to H-J-K-L keys. I added the new user at the end of the file and saved it. I also logged out from my ‘root’ account, as my job was finished.

What I didn’t noticed, when I was fiddling with the cursor keys, was that the first two letters of the username of the first account of the file changed to capitals.

“No big deal”, you might say, except that the first account in /etc/passwd file was ‘root’! And it became ‘ROot’, without noticing it!

Imagine my frustration when I tried to login back to root’s account, without knowing what actually had happen! 🙁

I don’t remember exactly what error messages I saw, but I ended that by rebooting the machine in single user mode, mounting the root partition in a directory and recovering back the root account.

What this little story taught me, was to double-check always what I’m doing as root, especially if the keys I’m pressing don’t have the expected result.


Visit The Light of the LAMP blog for more…