Here’s the top feeds you should be subscribed to (CVE tags are reported in brackets):

1. NIST Vulnerability Database.
2. US Cert Technical Security Alerts [CERT].
3. SecurityFocus Vulnerabilities [SF-INCIDENTS].
4. Open Source Vulnerability Database [OSVDB].
5. IBM Internet Security Systems Threats [ISS].
6. Vupen Security Advisories [VUPEN].
7. Secunia Latest Security Advisories (Unofficial) [SECUNIA].
8. eEye Security Advisories [EEYE].

The above list is also available as OPML file you can import into your feed reader.

Furthermore, you should subscribe to Operating Systems product-centric vulnerability feeds to ensure you receive timely information regarding updated packages and suggested workarounds for your infrastructure. Here’s a comprehensive list, sorted alphabetically:

1. Apple Security Announce (Mac OS X, iPhone, etc) [APPLE].
2. Checkpoint’s SmartDefense Service [CHECKPOINT].
3. Cisco’s Product & Service Security Advisories [CISCO].
4. Debian Security Advisories [DEBIAN].
5. Fedora Security Updates [FEDORA].
6. FreeBSD Security Advisories [FREEBSD].
7. Gentoo Linux Security Advisories (GLSA) [GENTOO].
8. Mandriva Security Advisories [MANDRIVA].
9. Microsoft’s Security Notification Service Comprehensive Edition [MS].
10. NetBSD Security Advisories [NETBSD].
11. OpenPKG Security Advisories [OPENPKG].
12. OpenBSD Errata [OPENBSD].
13. Red Hat Security Advisories [REDHAT].
14. Slackware Linux Security Advisories [SLACKWARE].
15. Solaris SunSolve Alerts [SUNALERT].
16. SUSE Linux Enterprise Security Advisories (also contains OpenSUSE advisories) [SUSE].
17. Ubuntu Security Notices [UBUNTU].

OS security advisory feeds are available as OPML file as well.

Have I missed anything? Please report if you find some advisory feed I accidentally missed. Also, if you’re into an Operating System security team and you don’t offer a security announcement feed, please consider making it available.

Being a Django monkey, I’d like to share some tips on how to make WordPress and Django live together:

URL mapping

To make WordPress and Django co-exist, they should map to different parts of the url space: you can simply configure them to respond on different virtual hosts, or just map WordPress to a specific path. For instance, if your webserver is Apache and you’re serving Django through mod_wsgi, you can use a config snippet like this:

<VirtualHost *:80>
ServerName somehost.com
ServerAdmin hostmaster@somehost.com
ErrorLog /path/to/somehost.com/log/error.log
CustomLog /path/to/somehost.com/log/access.log combined
DirectoryIndex index.html
DocumentRoot /var/empty
WSGIScriptAlias / /path/to/somehost.com/parts/wsgi/wsgi
WSGIDaemonProcess somehost.com user=www group=www threads=25
WSGIProcessGroup somehost.com
Alias /blog/ /path/to/somehost.com/wordpress/
Alias /media/ /path/to/somehost.com/project/media/

<Directory /path/to/somehost.com/wordpress/>
Order allow,deny
Allow from all
</Directory>

<Directory /path/to/somehost.com/media/>
Order allow,deny
Allow from all
</Directory>
</VirtualHost>

Accessing data

To share data between your WordPress blog and your Django instance, you have two three main options:

1. Save your WordPress tables and your Django models in the same database and configure your Django models accordingly.
   Pros: this approach is very straightforward and you don’t need to learn WordPress API. You can use Django admin interface to edit your WordPress database.
   Cons: sharing a database between two applications can have an impact on maintenance issues. For example, to rehash your Django application, you can’t just drop database, re-create it and populate with syncdb. WordPress database schema can change in new releases and make your ORM mapping obsolete.
2. Use Python’s xmlrpclib in Django to access WordPress XML-RPC interface.
   Pros: API changes won’t possibly break compatibility with previous releases. XML-RPC adds more logic, which means more consistency checks and more behind-the-curtain processing.
   Cons: XML-RPC calls are not as performant as direct access to MySQL.
3. UPDATE: Doug pointed me to another method: adding a PHP template loader to Django. An useful video tutorial is also available.

To setup method 1, you can use models.py from django-wordpress-admin project, which was built around inspectdb output with some custom manager enhancements. On GitHub there’s another project named django-wordpress, with the same approach and a step-by-step tutorial is published at uswaretech.com.

If you found Django-Wordpress integration tips useful, please drop a note in the comment box below to say how you used it, or just stay in touch with Twitter or RSS Feed for more Django stories.

How many times did you start a long-running task like gcc compilation on a remote server and then suddenly needed to disconnect from your shell? Maybe you just needed to move to some other place with your laptop, but if you disconnected from your LAN, your ssh connection would go down. How many times you thought “Damn, if I had launched screen before this…”?

The trick to save your compile time and not break your schedule is simple: just have your shell .profile script run screen at startup on your remote server. For bash, the syntax is simple, just add the following line at the end of your ˜/.profile script:

if [ ${SHLVL} -eq 1 ]; then
    ((SHLVL+=1)); export SHLVL
    exec screen -R -e "^Ee" ${SHELL} -l
fi

Quick implementation notes:

1. Parameter -R reattaches to an existing detached session, if it exists, otherwise creates a new one.
2. Parameter -e sets a non-standard escape character. This is useful since you don’t want login screen to interfere with other screens you may spawn during your activity. I chose Ctrl-E as it’s not used by other well-known keyboard shortcuts and works on most OSes.

To detach from your server type Ctrl-E d or just close your terminal window. Running processes will remain active in background, without detaching from your shell. When you connect to your remote shell again, you’ll get back to your session.

Do you like Unix tips like this? Follow me on Twitter or subscribe to my RSS feed for more.

1. Blueprint CSS framework

While not a django-specific add-on, Blueprint CSS framework is a perfect companion for django template designers: it features cross-browser style reset, a 24-column grid layout, a nice looking typography and a print-friendly style.

2. django-uni-form

django-uni-form implements UniForm CSS framework in Django: you can render your forms as stylish xhtml-compliant divs using a simple template tag filter and add form layout information to your Form classes.

3. django-compress

Optimization of CSS and Javascript distribution can greatly improve web client rendering times: django-compress outputs concatenated and minified files and handles smart client-side caching.

4. django-userskins

Using django-userskins you can enable user-selected themes in your application.

5. django-tabs

For your navigation bar, you can use django-tabs to highlight active tab (possibly with multiple navigation layers), by combining Django template extension mechanism and a special template tag.

6. django-reversetag

Default url tag is quite primitive, but using reverse tag introduce by django-reversetag, you can resolve urls from variables and string literals, which is very useful if your view or named view is computed at run-time.

7. macros template tags

Django macros template tags help you apply DRY criterias in your templates, while maintaining separation between presentation and logic. Download macros.py and save it into your app’s templatetags folder.

8. smart_if template tags

smart_if template tag add-on replaces default if/else/endif tags with a custom version that allows basic yet useful value comparisons. Download smart_if.py and save it into your app’s templatetags folder.

Tip: original smart_if doesn’t support elif syntax. You can find amended version here.

# mdadm --zero-superblock devicepath

If you need to apply this fix on a system that doesn’t boot up (for instance when your root volume is on RAID), remember that mdadm and other disk administration utilities are available in Gentoo minimal installation disk.

UPDATE: Rav asked for the gory details so here it is: when you initially create a Linux RAID array, mkraid writes a signature to the disk called superblock, which contains a unique UUID code for the array and a description of the array (size, raid level, etc). When Linux kernel boots up, this superblock is read by the md kernel module and a minor device number is assigned to the array. Even if you erase your partition table or mbr, this superblock won’t be erased.
The problem arises when you try to add a disk with an existing superblock to a computer that already has another array in place (for instance when replacing a faulty RAID1 or RAID5 disk): if md driver recognises a superblock, it won’t allow your added drive to join the array and will report a generic “Invalid argument” error. Furthermore, it can happen that, if a minor number is forced onto an array, when booting a system with two parts of arrays trying to grab the same minor, none of them can get through and therefore md devices are not available.
So, instead of zeroing the whole disk with dd if=/dev/zero of=/dev/path, which can take a certain amount of time and is quite useless (if you’re rebuilding RAID1 or RAID5, your disk contents will be overwritten by raid reconstruction anyway), you can use the command explained at the beginning to erase just the bad superblock and fix the problem.

Just a final notice: another problem with replacing disks in RAID1 and RAID5 happens when people try to use a volume which is slightly smaller than the others in the array (even if advertised capacity is the same of the old drives, there can be slight differences in actual number of blocks). In this case, the error reported from md upon loading is the same as above: “Invalid argument”. So if your disk is unused, this is probably the first thing to check, otherwise try the following command on the disk device to check for existing superblocks:

# mdadm -E devicepath