This site has no ads. To help with hosting, crypto donations are accepted:
Bitcoin: 1JErV8ga9UY7wE8Bbf1KYsA5bkdh8n1Bxc
Zcash: zcLYqtXYFEWHFtEfM6wg5eCV8frxWtZYkT8WyxvevzNC6SBgmqPS3tkg6nBarmzRzWYAurgs4ThkpkD5QgiSwxqoB7xrCxs
Fri, 30 Mar 2012
/SW/chat:
An Unofficial but Working QQ Plugin for Pidgin
The official Pidgin QQ support disappeared[1] quite some time ago after it stopped working. However, there is a
Chinese project[2] on Google Code that is currently delivering a working Ubuntu deb package. On my Debian testing
machine, to /etc/apt/sources.list, per [3] I added
deb http://ppa.launchpad.net/lainme/libqq/ubuntu precise main
then
apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 7C24E5AB949045F5
to avoid key complaints in the install, and then:
apt-get update
apt-get install libqq-pidgin
followed by a Pidgin restart, and QQ appears as an account option. All I needed to authenticate were my
QQ userid and password, it just worked, and so far no sign of those annoying captchas!
Lord, am I glad to get rid of those official, closed-source QQ clients! Running that stuff, even WebQQ, on my
personal machine gave me a SEVERE case of the creeps. Mind you, it must be noted that packages pulled from PPA are
unofficial, but they are 100% Open Source with the code available for all to see, and I am seeing at least five people
declared as working on the project. A worthy project for someone with free time....
[1] http://developer.pidgin.im/ticket/13193
[2] https://code.google.com/p/libqq-pidgin/
[3] https://code.google.com/p/libqq-pidgin/wiki/UbuntuUsers
posted at: 21:54 | path: /SW/chat | permanent link to this entry
Fri, 23 Mar 2012
/Admin/backups/dirvish:
Simple, Elegant, Small-Enterprise Backups with Dirvish
I do not like Bacula, Backuppc has some issues, rdiff-backup is too crude, where to turn for rock-solid backups?
Rsync-based Dirvish[1] is making me very happy at the moment:
- simple configuration file setup, only a couple of hours necessary to get off the ground
- backups are de-duped (but not compressed)
- backup sets are easy to find and available unobfuscated on the backup server file system, simply copy to restore
- dirvish is another layer of abstraction on top of the rock-solid foundation of rsync and rdiff-backup
- Documentation[2][3] is not copious, but not deficient either
As a layer on top of rdiff-backup, Dirvish's basic operation is the same: the first backup rsyncs all non-excluded
files and directories. (Obviously, this may be quite a chunk of time and bandwidth if we are talking about a remote
server with a large file system.) Thereafter, each succeeding backup is an rsync of just the changes since the last
backup. Adjacent backups appear as directories with the entire contents of the backup within, BUT files that are the
same are hard linked, ie. only the delta is taking up actual storage space. This means that pruning old backups
simply consists of deleting the directories they are contained in, with hard-linking automatically taking care of the
house-keeping for remaining adjacent backups. And it means that maintaining a complete backup of a remote server is
reasonable, since after the first backup only incremental changes go over the network on subsequent backups.
What Dirvish adds on top of rdiff-backup is:
- configuration via a simple set of configuration files
- cron framework that automatically performs backups, and prunes old backups according to rules
- displays all past backup sets as visible directories (rdiff-backup only does this for the most recent
backup, and obfuscates older backup sets).
- pre- and post-backup hooks for those who want them (MySQL dumps, for instance).
On Debian-based systems the framework is already setup with a cronjob that will, by default, fire at 2200 and
prune/refresh all backups. Configuration involves creating an /etc/dirvish/master.conf that orchestrates the whole
process, and creating a set of directories to house your Dirvish "banks" (groupings of backups) and "vaults" (each
"vault" is a directory tree on a specific machine). And then inside each "vault" adding a dirvish/default.conf file
that gives specific direction for that particular backup.
For instance, /etc/dirvish/master.conf:
bank:
/home/backups/dirvish-local
/home/backups/dirvish-officeServer
/home/backups/dirvish-ibmProductionServer
exclude:
lost+found/
core
*~
.nfs*
tmp
/proc
/sys
/dev
/var/cache/apt/archives/*.deb
Runall:
local-root 22:00
ibmFull 22:00
officeEtc 22:00
officeWWW 22:00
officeMySQL 22:00
expire-default: +15 days
expire-rule:
# MIN HR DOM MON DOW STRFTIME_FMT
* * * * 1 +3 months
# * * 1-7 * 1 +1 year
* * 1-7 1,4,7,10 1 +1 year
* 10-20 * * * +4 days
# * * * * 2-7 +30 days
In the above, for instance, officeEtc / officeWWW / officeMySQL are all "vaults" for which I have created subdirectories
under /home/backups/dirvish-officeServer. This file defines what is backed up, and a set of defaults for all "vaults".
For instance, the above expire rules will keep 15 days of daily backups, three months of weekly backups, and one year of
quarterly backups for all vaults, unless there are local vault rules that over-ride this behavior.
An example vault config file, /home/backups/dirvish-ibmProductionServer/ibmFull/dirvish/default.conf:
client: prodServer
tree: /
xdev: 0
index: gzip
log: gzip
image-default: %Y%m%d
speed-limit: 100
exclude:
"prodServer" must appear in /etc/hosts or resolve via DNS. "tree: /" tells us we are backing up the whole server.
"speed-limit: 100" uses the same syntax as rsync, and limits bandwidth to 100 kB/s.
Normally after setting up all the configuration files, one tests the configuration by
setting the "tree" parameter to a relatively small subdirectory in each vault in turn, and
running:
<![CDATA[
dirvish --vault <vault-name> --init
]]>
for each vault. This causes that tree to be backed up immediately, and you can see and correct any errors.
After all is working, reset "tree" to the desired value, and check a couple days later to see if everything is working
as expected.
[1] http://www.dirvish.org/
[2] http://www.dirvish.org/docs.html
[3] http://wiki.edseek.com/howto:dirvish
posted at: 03:31 | path: /Admin/backups/dirvish | permanent link to this entry
