I’ve just read an amusing series of blog posts about bad wiring [1]. I’ve seen my share of wiring horror in the past. There are some easy ways of minimising wiring problems which seem to never get implemented. The first thing to do is to have switches near computers. Having 48 port switches in a server room and wires going across the building causes mess and is difficult to manage. A desktop machine doesn’t need a dedicated Gig-E (or even 100baseT) connection to the network backbone. Cheap desktop switches installed on desks allow one cable to go to each group of desks (or two cables if you have separate networks for VOIP and data). If you have a large office area then a fast switch in the corner of the room connecting to desktop switches on the desks is a good way to reduce the cabling requirements. The only potential down-side is that some switches are noisy, the switches with big fans can be easily eliminated by a casual examination, but the ones that make whistling sounds from the PSU need to be tested first. The staff at your local electronics store should be very happy to open one item for inspection and plug it in if you are about to purchase a moderate number (they will usually do so even if you are buying a single item). A common objection to this is the perceived lack of reliability of desktop switches. One mitigating factor is that if a spare switch is available the people who work in the area can replace a broken switch. Another is that my observation is that misconfiguration on big expensive switches causes significantly more down-time than hardware failures on cheap switches ever could. A cheap switch that needs to be power-cycled once a month will cause little interruption to work, while a big expensive switch (which can only be configured by the “network experts” - not regular sysadmins such as me) can easily cause an hour of down-time for most of an office during peak hours. Finally the reliability of the cables themselves is also an issue, having two cables running to the local switch in every office can allow an easy replacement to fix a problem - it can be done without involving the IT department (who just make sure that both cables are connected to the switch in the server room). If there is exactly one cable running to each PC from the server room and one of the cables fails then someone’s PC will be offline for a while. In server rooms the typical size of a rack is 42RU (42 Rack Units). If using 1RU servers that means 42 Ethernet cables. A single switch can handle 48 Ethernet ports in a 1RU mount (for the more dense switches), others have 24 ports or less. So a single rack can handle 41 small servers and a switch with 48 ports (two ports to go to the upstream switch and five spare ports). If using 2RU servers a single rack could handle 20 servers and a 24port switch that has two connections to the upstream switch and two spare ports. Also it’s generally desirable to have at least two Ethernet connections to each server (public addresses and private addresses for connecting to databases and management). For 1RU servers you could have two 48 port switches and 40 servers in a rack. For 2RU servers you could have 20 servers and either two 24port switches or one 48port switch that supports VLANs (I prefer two switches - it’s more difficult to mess things up when there are two switches, if one switch fails you can login via the other switch to probe it, and it’s also cheaper). If the majority of Ethernet cables are terminated in the same rack it’s much harder for things to get messed up. Also it’s very important to leave some spare switch ports available as it’s a common occurrence for people to bring laptops into a server room to diagnose problems and you really don’t want them to unplug server A to diagnose a problem with server B… Switches should go in the middle of the rack. While it may look nicer to have the switch at the top or the bottom, that means that the server which is above or below it will have the cables for all the other switches going past it. Ideally the cables would go in neat cable runs at the side of the rack but in my experience they usually end up just dangling in front. If the patch cables are reasonably short and they only dangle across half the servers things won’t get too ugly (this is harm minimisation in server room design). The low end of network requirements is usually the home office. My approach to network design for my home office is quite different, I have no switches! I bought a bunch of dual-port Ethernet cards and now every machine that I own has at least two Ethernet ports (and some have as many as four). My main router and gateway has four ports which allows connections from all parts of my house. Then every desktop machine has at least two ports so that I can connect a laptop in any part of the house. This avoids the energy use of switches (I previously used a 24 port switch that drew 45W [2]), switches of course also make some noise and are an extra point of failure. While switches are more reliable than PCs, as I have to fix any PC that breaks anyway my overall network reliability is increased by not using switches. For connecting the machines in my home I mostly use bridging (only the Internet gateway acts as a router), I have STP enabled on all machines that have any risk of having their ports cross connected but disable it on some desktop machines with two ports (so that I can plug my EeePC in and quickly start work for small tasks).

• [1] http://www.darkroastedblend.com/2008/08/crazy-wiring-part-5.html


• [2] http://doc.coker.com.au/environment/computer-related-power-use/

Share This

I'm doing some contracting work at a local firm, and one of the little details that I have been pleased with is the fact that they seem to do introductions for people. On my first day, I was taken around and introduced to everyone, despite the fact that I probably won't be there long term (depending on where we go and when). Today, they were showing around a guy who will be doing a sort of student internship there, and once again, they stopped by my office. I appreciate that a lot, and think that it's a good thing for a group of people to at least have a bit of an idea who newcomers are. One of the things that I have always loathed, and vowed to do differently should DedaSys ever be more than myself, is feeling like an animal in a zoo when The Boss brought someone into the office to take them on a tour, pointing at us developers and talking about what we do, with no reciprocity. "This is Dave, one of our open source guys, who is really into Linux. He once roamed the temperate forests of Oregon and his mating season is from early January to late December." We get pointed at and talked about, and the other person remains a Mysterious Stranger. Granted, it's not always possible to disclose everything, but I think that you can still do a lot to make people feel respected without spilling the beans on a big potential customer or investment.

According to a recent article, 6 Common Website Mistakes That Cost Money are:

1. JavaScript or other crawler-unfriendly navigation that may impede indexing

This one is best avoided at design-time, by including Web Content Accessibility Guidelines 1.0 Level A in the design brief, but if you’ve ended up with JavaScript-based navigation on your site (check by doing “View Source” and searching for the code for your home page link and so on - if you can find it, then it’s probably not javascript) and it’s based on some template system, a webmaster can probably do a whole-site edit to put the navigation links in the page properly - or at least add a useful <noscript> tag.

2. Navigation that buries important pages within the site architecture.

The structure of the website’s files and the structure of the link menus do not need to match, so if there’s a page that you feel is important, get your webmaster to add it to the navigation links across the whole site.

3. Duplicate “pages” getting indexed under multiple URLs.

This usually happens for one of two reasons: one is inappropriately-parked domains, which is mistake 6 below and often fairly easy to fix; the other is a misbehaving web application, which you’ll need to get a programmer to fix. You can do a simple test of your web application by starting at your homepage and following links to a particular page; then open a new browser window and try to reach the same page by different links (or a site search) and compare the address bars (the bit of your browser showing http://) - do they match? If not, you’ve got this problem.

4. No keyword phrase focus in the content or conversely, keyword phrase stuffing

You can use a good word-counter on the text to see how common different keywords and keyphrases, or use the “webmaster tools” section of some search engines to see what they’re focusing on. Keyword-stuffing can be fairly easy to see. If you “View Source” on a page and there’s a large block of keyword-intensive text somewhere in it that doesn’t appear it when viewed in a browser, then it’s probably stuffing. Many sites regard stuffing as a sort of spam, so you don’t want to be found doing this. To fix these problems, rewrite the page text appropriately.

5. An optimized home page, but that’s it

Repeat your checks from problem 4 on a few pages other than the home page to discover whether you suffer from this. Also, see whether your website statistics show search engine visitors arriving at a variety of different pages (these are sometimes called “Entry Page” statistics).

6. Additional domains owned by the company are not properly redirected

If you usually use .co.uk, but you also have a .com domain, try visiting a random page on your website, then click in the address bar and replace the .co.uk with .com - what happens? If the page is Not Found, then your domains aren’t properly redirected and you need a Redirect adding to the second one. If the page displays but the address doesn’t change itself back, then your domains are probably pointing at the same webspace but aren’t properly redirected, which will mean you’re probably making mistake 3 above. Usually, the simplest way to fix this is with a conditional redirect. On Apache webservers, you can add a .htaccess file containing something like:-

RewriteEngine On
RewriteCond % HTTP_HOST  !^www\.yourdomain\.co\.uk$ [NC]
RewriteRule (.*) http://www.yourdomain.co.uk/$1 [R=permanent,L]

That even works on BT Business web hosting, by the way. If it doesn’t work, try asking your web hosting provider to enable mod_rewrite for you or ask them to suggest how to achieve the same result.

The above list of mistakes was published on Search Engine Land last week. The correction methods are all things used by my webmaster cooperative.

As everyone can see in the graph of release critical bugs, the number of RC bugs in etch had constantly risen since the release (which was already noted in some other blogs) up until last week. Since I suspected that this number included a lot of false positives, I began to triage this list last week during Debconf. I started with identifying all bugs that were filed against the version in etch, but really only meant the package in testing/unstable (but can't be interpreted correctly with version tracking alone since the version in stable, testing, and unstable is actually identical). There are a lot of reasons why an RC bug might be valid for testing/unstable, but not for stable, even though they share the same package:

Library transitions.

While most cases of library transitions can be handled with targeted binNMUs these days, there remain a few cases where a sourceful upload is needed, e.g. for renamed -dev packages and necessary source changes to adapt to new APIs.

Build-Problems caused by toolchain changes.

Newer gcc versions are often more strict about what constructs they allow. This can cause build problems in a lot of packages once the default version used is increased. Other packages that regulary cause new build problems are linux-libc-dev and dpkg-dev. Since we only require that a package is buildable in the release it is contained in, these are not valid RC bugs for stable.

Changes in the RC policy of the release team.

One example during the lenny release cycle was the use of invoke-rc.d in maintainer scripts to (re-)start daemons. Bugs were filed against a lot of packages not using invoke-rc.d before the etch release but they were only declared to be of RC severity after etch.

etc.

So as the first part of my triaging efforts I tried to identify these cases. I also looked for bugs that were listed as affecting etch due to incomplete version information (i.e. if there is no version given, the bug is assumed to affect all versions). As you can see from the bump in the graph I was able to identify about 200 bugs that met one of these conditions. We should avoid in the future to let the number of false positives grow to such large numbers. Everyone can help with that:

Maintainers

If you get bugs reported without a version number and you can verify that this bug was not present in an older version of the package, add correct "found" information. If you get a bug reported against a version that is both in stable and in testing/unstable, but not valid for stable, tag the bug appropriatly. I would recommend to err on the side of false positives though instead of on the side of false negatives!

Mass-bug filers

Most mass-bug filing that involve RC bugs should use tags to avoid creating false positives.

QA Group

Bugs filed about the proposed orphaning or removal of packages should usually be tagged, since only in very few cases these actually warrant any changes in stable.

At this point you probably ask yourself: What are the appropriate tags? This is much less clear than one might hope, since the involved tags (<suite>) changed/lost their meaning somewhat with the introduction of version tracking. Following my question about the appropriate tags on debian-release the release team and Don Armstrong for the debbugs maintainers seem to have agreed on their new meaning: A bug with suite tags affects the intersection of the set of suites indicated by its version information and the set of suites indicated by its suite tags. Next post: What about the other 600 RC bugs in stable?

At the moment there are ongoing security issues related to web based services and DNS hijacking. the Daily Ack has a good summary of the session hijacking issue [1]. For a long time it has been generally accepted that you should configure a DNS server to not allow random machines on the Internet to copy the entire zone. Not that you should have any secret data there anyway, but it’s regarded as just a precautionary layer of security by obscurity. Dan Kaminsky (who brought the current DNS security issue to everyone’s attention) has described some potential ways to alleviate the problem [2]. One idea is to use random case in DNS requests (which are case insensitive but case preserving), so if you were to lookup wWw.cOkEr.CoM.aU and the result was returned with different case then you would know that it was forged. Two options which have been widely rejected are using TCP for DNS (which is fully supported for the case where an answer can not fit in a single UDP packet) and sending requests twice (to square the number of combinations that would need to be guessed). They have been rejected due to the excessive load on the servers (which are apparently already near capacity). One option that does not seem to get mentioned is the possibility to use multiple source IP addresses, so instead of merely having 2^16 ports to choose from you could multiply that by as many IP addresses as you have available. In the past I’ve worked for ISPs that could have dedicated a /22 (1024 IP addresses) to their DNS proxy if it would have increased the security of their customers - an ISP of the scale that has 1024 spare IP addresses available is going to be a major target of such attacks! Also with some fancy firewall/router devices it would not be impossible to direct all port 53 traffic through the DNS proxies. That would mean that an ISP with 200,000 broadband customers online could use a random IP address from that pool of 200,000 IP addresses for every DNS request. While attacking a random port choice out of 65500 ports is possible, if it was 65500 ports over a pool of 200,000 IP addresses it would be extremely difficult (I won’t claim it to be impossible). One problem with the consideration that has been given to TCP is that it doesn’t account for the other uses of TCP, such as for running DNS secondaries. In Australia we have two major ISPs (Telstra and Optus) and four major banks (ANZ, Commonwealth, NAB, and Westpac). It shouldn’t be difficult for arrangements to be made for the major ISPs to have their recursive DNS servers (the caching servers that their customers talk to) act as slaves for the DNS zones related to those four banks (which might be 12 zones or more given the use of different zones for stock-broking etc). If that was combined with a firewall preventing the regular ISP customers (the ones who are denied access to port 25 to reduce the amount of spam) from receiving any data from the Internet with a source port of 53 then the potential for attacks on Australian banks would be dramatically decreased. I note that the Westpac bank has DNS secondaries run by both Optus and Telstra (which makes sense for availability reasons if nothing else), so it seems that the Telstra and Optus ISP services could protect their customers who use Westpac without any great involvement from the bank. Banks have lots of phone lines and CTI systems. It would be easy for each bank to have a dedicated phone number (which is advertised in the printed phone books, in the telephone “directory assistance” service, and in brochures available in bank branches - all sources which are more difficult to fake than Internet services) which gave a recorded message of a list of DNS zone names and the IP addresses for the master data. Then every sysadmin of every ISP could mirror the zones that would be of most use to their customers. Another thing that banks could do would be to create a mailing list for changes to their DNS servers for the benefit of the sysadmins who want to protect their customers. Signing mail to such a list with a GPG key and having the fingerprint available from branches should not be difficult to arrange. Another possibility would be to use the ATM network to provide security relevant data. Modern ATMs have reasonably powerful computers which are used to display bank adverts when no-one is using them. Having an option to press a button on the ATM to get a screen full of Internet banking security details of use to a sysadmin should be easy to implement. For full coverage (including all the small building societies and credit unions) it would be impractical for every sysadmin to have a special case for every bank. But again there is a relatively easy solution. A federal agency that deals with fraud could maintain a list of zone names and master IP addresses for every financial institution in the country and make it available on CD. If the CD was available for collection from a police station, court-house, the registry of births, deaths, and marriages, or some other official government office then it should not have any additional security risks. Of course you wouldn’t want to post such CDs, even with public key signing (which many people don’t check properly) there would be too much risk of things going wrong. In a country such as the US (which has an unreasonably large number of banks) it would not be practical to make direct deals between ISPs and banks. But it should be practical to implement a system based on a federal agency distributing CDs with configuration files for BIND and any other DNS servers that are widely used (is any other DNS server widely used?). Of course none of this would do anything about the issue of Phishing email and typo domain name registration. But it would be good to solve as much as we can.

• [1] http://www.dailyack.com/2008/08/cookie-hijacking.html


• [2] http://www.doxpara.com/?p=1215

Share This

A large part of the disagreement about the way to manage the policy seems to be based on who will be the primary “owner” of the policy on the machine. This isn’t a problem that only applies to SE Linux, the same issue applies for various types of configuration files and scripts throughout the process of distribution development. Having a range of modules which can be considered configuration data that come from a single source seems to make SE Linux policy unique among other packages. The reasons for packaging all Apache modules in the main package seem a lot clearer. One idea that keeps cropping up is that as the policy is modular it should be included in daemon packages and the person maintaining the distribution package of the policy should maintain it. The reason for this request seems to usually be based on the idea that the person who packages a daemon for a distribution knows more about how it works than anyone else, I believe that this is false in most cases. When I started working on SE Linux I had a reasonable amount of experience in maintaining Debian packages of daemons and server processes, but I had to learn a lot about how things REALLY work to be able to write good policy. Also if we were to have policy modules included in the daemon packages, then those packages would need to be updated whenever there were serious changes to the SE Linux policy. For example Debian/Unstable flip-flopped on MCS support recently, changing the policy packages to re-enable MCS was enough pain, getting 50 daemon packages updated would have been unreasonably painful. Then of course there is the case where two daemons need to communicate, if the interface which is provided with one policy module has to be updated before another module can be updated and they are in separate packages then synchronised updates to two separate packages might be required for a single change to the upstream policy. I believe that the idea of having policy modules owned by the maintainers of the various daemon packages is not viable. I also believe that most people who package daemons would violently oppose the idea of having to package SE Linux policy if they realised what would be required of them. Caleb Case seems to believe that ownership of policy can either be based on the distribution developer or the local sys-admin with apparently little middle-ground [1]. In the section titled “The Evils of Single Policy Packages” he suggests that if an application is upgraded for a security fix, and that upgrade requires a new policy, then it requires a new policy for the entire system if all the policy is in the same package. However the way things currently work is that upgrading a Debian SE Linux policy package does not install any of the new modules. They are stored under /usr/share/selinux/default but the active modules are under /etc/selinux/default/modules/active. An example of just such an upgrade is the Debian Security Advisory DSA-1617-1 for the SE Linux policy for Etch to address the recent BIND issue [2]. In summary the new version of BIND didn’t work well with the SE Linux policy, so an update was released to fix it. When the updated SE Linux policy package is installed it will upgrade the bind.pp module if the previous version of the package was known to have the version of bind.pp that didn’t allow named to bind() to most UDP ports - the other policy modules are not touched. I think that this is great evidence to show that the way things currently work in Debian work well. For the hypothetical case where a user had made local modifications to the bind.pp policy module, they could simply put the policy package on hold - I think it’s safe to assume that anyone who cares about security will read the changelogs for all updates to released versions of Debian, so they would realise the need to do this. Part of Caleb’s argument rests on the supposed need for end users to modify policy packages (IE to build their own packages from modified source). I run many SE Linux machines, and since the release of the “modular” policy (which first appeared in Fedora Core 5, Debian/Etch, and Red Hat Enterprise Linux 5) I have never needed to make such a modification. I modify policy regularly for the benefit of Debian users and have a number of test machines to try it out. But for the machines where I am a sysadmin I just create a local module that permits the access that is needed. The only reason why someone would need to modify an existing module is to remove privileges or to change automatic domain transition rules. Changing automatic domain transitions is a serious change to the policy which is not something that a typical user would want to do - if they were to do such things then they would probably grab the policy source and rebuild all the policy packages. Removing privileges is not something that a typical sysadmin desires, the reference policy is reasonably strict and users generally don’t look for ways to tighten up the policy. In almost all cases it seems best to consider that the policy modules which are shipped by the distribution are owned by the distribution not the sysadmin. The sysadmin will decide which policy modules to load, what roles and levels to assign to users with the semanage tool, and what local additions to add to the policy. For the CentOS systems I run I use the Red Hat policy, I don’t believe that there is a benefit for me to change the policy that Red Hat ships, and I think that for people who have less knowledge about SE Linux policy than me there are more reasons not to change such policy and less reasons to do so. Finally Caleb provides a suggestion for managing policy modules by having sym-links to the modules that you desire. Of course there is nothing preventing the existence of a postfix.pp file on the system provided by a package while there is a local postfix.pp file which is the target of the sym-link (so the sym-link idea does not support the idea of having multiple policy packages). With the way that policy modules can be loaded from any location, the only need for sym-links is if you want to have an automatic upgrade script that can be overridden for some modules. I have no objection to adding such a feature to the Debian policy packages if someone sends me a patch. Caleb also failed to discuss how policy would be initially loaded if packaged on a per-module basis. If for example I had a package selinux-policy-default-postfix which contains the file postfix.pp, how would this package get installed? I am not aware of the Debian package dependencies (or those of any other distribution) being about to represent that the postfix package depends on selinux-policy-default-postfix if and only if the selinux-policy-default package is installed. Please note that I am not suggesting that we add support for such things, a package management system that can solve Sudoku based on package dependency rules is not something that I think would be useful or worth having. As I noted in my previous post about how to package SE Linux policy for distributions [3] the current Debian policy packages have code in the postinst (which I believe originated with Erich Schubert) to load policy modules that match the Debian packages on the system. This means that initially setting up the policy merely requires installing the selinux-policy-default package and rebooting. I am inclined to reject any proposed change which makes the initial install of of the policy more difficult than this. After Debian/Lenny is released I plan to make some changes to the policy. One thing that I want to do is to have a Debconf option to allow users to choose to automatically upgrade their running policy whenever they upgrade the Debian policy package, this would probably only apply to changes within one release (IE it wouldn’t cause an automatic upgrade from Lenny+1 policy to Lenny+2). Another thing I would like to do is to have the policy modules which are currently copied to /etc/selinux/default/modules/active instead be hard linked when the source is a system directory. That would save about 12M of disk space on some of my systems. I’ve taken the unusual step of writing two blog posts in response to Caleb’s post not because I want to criticise him (he has done a lot of good work), but because he is important in the SE Linux community and his post deserves the two hours I have spent writing responses to it. While writing these posts I have noticed a number of issues that can be improved, I invite suggestions from Caleb and others on how to make such improvements.

• [1] http://www.calebcase.com/node/2


• [2] http://lists.debian.org/debian-security-announce/2008/msg00201.html


• [3] http://etbe.coker.com.au/2008/08/18/se-linux-policy-packaging-distribution/

Share This

Following the recent post about my issues with byte swapping on amd64, I have received several answers.. Since comments were broken, Rupert sent me a good explanation of the cryptic code from OSS4. Let me remember you what it was doing: The code is indeed very simple, but it has to be decomposed carefully.. First, the author assumes that unsigned char = one byte, which seems reasonable. Then, a is initialised at the second character of the two-characters value x, and b on the first of the returned (swapped) value y. Now, the two cryptic lines can be decomposed as follows: *(b++) = *(a--), which literally means "put in b the value from a, and then increase b and decrease a. When executing the second line, a points to the first character from x, and b to the second from y. As Rupert noticed, the second call could simply have been *b = *a, but this wouldn't have been l33t enough :) Now, about the original code, namely (x 8) (x >> 8), MadCoder (salut !), as well as another anonymous comment both suggested that this would be a type error. Indeed, I had noticed the wrong right shift, but no matter how I tried, with or without mask, with unsigned short, short, or uint16_t, as suggested by MadCoder, I always get the same corrupted sound.. So, thanks for your comments, I'm now trying to dig the issue down in the code that makes use of this function. Most likely the issue comes from a wrong transtyping there.. I am also wondering what's the efficiency of the above OSS4's code with regard to (x 8) (x >> 8). Any idea ? PS: Yes, text on comments are mangled a lot. This is a basic safehtml protection, and I don't have the control over it, sorry..

So, DebConf8 is over (currently we have three machines left in the network, the video storage server, the video encoding server and my laptop...) and IMO it rocked! I really enjoyed being here, meeting many many known faces and getting to know quite some new ones and learning a bit here and there, even though I was mostly doing videoteam work :-)

And this should be the main message of this blog post: many many thanks to all the different members of the videoteam. You have been awesome! The camera operators, the sound and video mixers, the moderators (which strictly speaking are not part of the videoteam but nonetheless helped us very much), those of you who reviewed the videos, the debconf network admins, the localteam members who prepared the venue fantastically, those who prepaid for hardware (and Debian for paying in the end) and took it here, those who helped with the set up here, the hotel staff who generally were very helpful (for example they agreed to dig holes in their walls), the absent team members who helped via irc and very much Dami n Viano for his awesome work on pentabarf and Ben Hutchings for dvswitch and most of the debconf-video package.

Also I like to thank Amaya very much for bearing with me and for all the love and joy you give me! Te quiero!

Thank you all! Very very much.

(And now I'm curious who I forgot...)

I'm also really happy we got videoteam t-shirts this year and at the same time this is probably the biggest regret I have regarding the videoteam: We didn't have enough t-shirts for everyone who deserved one. But things can definitly be worse :-)

Recordings, as much as we have them, are being uploaded at the usual place. You can help us with post processing by adding comments about problems (non-obvious ones only, please. If a event is split into two files, thats an obvious problem), to our todo wikipage.

See you! Have fun!

I’ve just visited the Australian Business and IT Expo (ABITE) [1]. I haven’t been to such an event for a while, but Peter Baker sent a link for a free ticket to the LUV mailing list and I was a bit bored to I attended. The event was a poor shadow on previous events that I had attended. The exhibition space was shared with an event promoting recreational activities for retirees, and an event promoting wine and gourmet food. I’m not sure why the three events were in the room, maybe they figured that IT people and senior citizens both like gourmet food and wine. The amount of space used for the computer stands was small, and there was no great crowd of delegates - when they can’t get a good crowd for Saturday afternoon it’s a bad sign for the show. I have previously blogged about the idea of putting advertising on people’s butts [2]. One company had two women working on it’s stand with the company’s name on the back of their shorts. A representative of a company in the business of Internet advertising asked me how many hits I get on my blog, I told him 2,000 unique visitors a month (according to Webalizer) which seemed to impress him. Actually it’s about 2,000 unique visitors a day. I should rsync my Webalizer stats to my EeePC so I can give detailed answers to such questions. The IT event seemed mostly aimed at managers. There were some interesting products on display, one of which was a device from TabletPC.com.au which had quite good handwriting recognition (but the vocabulary seemed limited as it couldn’t recognise a swear-word I used as a test). Generally the event was fun (including the wine and cheese tasting) and I don’t regret going. If I had paid $10 for a ticket I probably would have been less happy with it. Updated to fix the spelling of “wine”. Not a “wind tasting”.

• [1] http://australianbusinessanditexpo.com.au/


• [2] http://etbe.coker.com.au/2008/06/15/what-is-appropriate-advertising/

Share This

One goal of Custom Debian Distributions is to form a group of Debian
developers who care for a specific set of packages that are used in
the day to day work of a certain user group. The fact that Debian has
grown to the largest pool of ready to install packages on the net has
led to the side effect that it is hard to maintain for
beginners. A Custom Debian Distribution adds some substructure
to the currently flat pool of 15000+X packages without a real
structure. These substructures are intended to put a focus on
special user interest. These substructures are not oriented on
technical matters like Debian installer team, porting teams or teams
that are focussing to implement programming language policies.

There are some similarities to Debian-i18n which also has the pure
goal to serve the needs of certain end user groups with the difference
that the users are grouped not according to their field of work but
according to their language. In fact it makes even sense to create
CDDs for languages that require certain technical means to optimally
support the language regarding direction of writing, special fonts
etc. It is known that some countries in Asia builded Debian
derivatives for this purpose but in principle it is not necessary to
derive - the better solution is to make Debian more flexible by
starting a CDD effort inside Debian.

The talks will give some examples from the success of CDDs like
Debian-Edu and Debian-Med. One very important outcome of the CDD
effort is the ongoing reunification of Linex - the Debian derived
distribution that is used in all schools in Extremadura - with
Debian-Edu. This step means that Debian gets a very large
implementation in all schools of Extremadura while on the other hand
the effort of development for the people who invented Linex will be
reduced. Debian featuring Debian-Edu now has a very good chance to
become a really good international school distribution because it has
roots in five countries (Norway, Spain, France, Germany and Japan) and
might become attractive for many more.

The success stories of CDDs would not have been possible outside
Debian and thus leaving the path to build Zillions of Debian
derivatives that reach a very small user base and working together
inside Debian is the main idea of the talk. To make this idea more
attractive in the second part of the talk a description of tools that
were developed in the CDD effort will be presented. Especially the
newly developed web tools that give a good overview about the
packages that are useful for a certain field of work and the QA tools
that enable the CDD team members to easily get an overview about
packages that need some action. So if people are not yet convinced
that a CDD for their purpose makes sense we will catch them by the
tools they might get for free if they follow the proposed strategy.
Full event details

Since 2005, the talks at Debconf have been recorded on video, to be
published online. Beginning in 2006, talks have also been streamed
live. One of the goals is to get recordings in high quality online
immediately, with little or no post-production work. The video
switcher dvswitch, realized in software, and a disk-based recording
workflow is bringing us closer to that goal. Tape is still used as
backup in case of failures, but we expect those to become rarer as
the system matures. A large part of the post production work is
restoring failed recordings.

Dvswitch was developed by Ben Hutchings just in time for the Debconf7
in Edinburgh. It enabled a multi-camera live production using cheap
cameras and modest laptops. The laptops relays DV streams over
TCP/IP. This avoids any degradation due to long cable stretches, and
makes cabling cheap and convenient. The output is DV straight from
the cameras, producing a very crisp master video.

Dvswitch works with sources and sinks. The sources send video from a
file or a firewire port to a listening instance of dvswitch, which can
run on a remote machine.
dvswitch listens to several sources and displays a scaled down black
and white preview image of each one. One of the sources is displayed
at full resolution in colour; this is the outgoing stream, which is
sent to the listening sinks. Each sink may send the stream to disk or
to an encoder for live streaming. It is common to do both; store the
raw master to disk, and forward the master to an encoder, and
subsequently to a streaming server.

While dvswitch saves us a bundle in hardware, the video team is still
heavy on manpower. Remotely operated cameras would help, and we are
still looking for affordable solutions that work well on Linux.


The talk will cover the hardware, software and manpower required for
a typical dvswitch usecase. Some caveats and challenges regarding
sound, lighting and rigging will be discussed. A live demonstration
of dvswitch in use will be given. We would also like to offer
rehearsal sessions with the demo rig for those who are interested.Full event details

Since 2005, the talks at Debconf have been recorded on video, to be
published online. Beginning in 2006, talks have also been streamed
live. One of the goals is to get recordings in high quality online
immediately, with little or no post-production work. The video
switcher dvswitch, realized in software, and a disk-based recording
workflow is bringing us closer to that goal. Tape is still used as
backup in case of failures, but we expect those to become rarer as
the system matures. A large part of the post production work is
restoring failed recordings.

Dvswitch was developed by Ben Hutchings just in time for the Debconf7
in Edinburgh. It enabled a multi-camera live production using cheap
cameras and modest laptops. The laptops relays DV streams over
TCP/IP. This avoids any degradation due to long cable stretches, and
makes cabling cheap and convenient. The output is DV straight from
the cameras, producing a very crisp master video.

Dvswitch works with sources and sinks. The sources send video from a
file or a firewire port to a listening instance of dvswitch, which can
run on a remote machine.
dvswitch listens to several sources and displays a scaled down black
and white preview image of each one. One of the sources is displayed
at full resolution in colour; this is the outgoing stream, which is
sent to the listening sinks. Each sink may send the stream to disk or
to an encoder for live streaming. It is common to do both; store the
raw master to disk, and forward the master to an encoder, and
subsequently to a streaming server.

While dvswitch saves us a bundle in hardware, the video team is still
heavy on manpower. Remotely operated cameras would help, and we are
still looking for affordable solutions that work well on Linux.


The talk will cover the hardware, software and manpower required for
a typical dvswitch usecase. Some caveats and challenges regarding
sound, lighting and rigging will be discussed. A live demonstration
of dvswitch in use will be given. We would also like to offer
rehearsal sessions with the demo rig for those who are interested.Full event details

Dear Lazyweb, I'm a permanent resident of one country, but I'm representing the interests of another one as a part of my job. Anyhow, I'm constantly traveling, so I cannot consider myself as having a residence anywhere in particular. Still, the health insurance and taxation offices of the country where I'm registered as a resident are constantly annoying me with requests for additional clarifications about "working abroad" (trying to imply that I might have relocated to the country where my employer has their head office), which is a complete waste of my time, because the previous explanation is never good enough for them and they keep on twisting every word I say. I was thus wondering if someone ever found a way to not have any official place of residence anywhere and still be able to get visas for the countries they need to visit and also be able to rent apartments in the countries that they visit the most frequently without ending up with residence permits for each of them, so as to avoid the above mess with multiple jurisdictions? This question is not about evading taxation. It's about finding a solution to avoid wasting time constantly filing paperwork just because the bureaucracy cannot understand a situation where someone's lifestyle doesn't fit the traditional model of living and working in exactly one city.

current temperatures:

• innsbruck, austria: 13°C
• mar del plata, argentina: 14°C

so much for european summer & south american winter.

Unfortunately, Matthew is correct, and it seems that Ryan Farmer is the idiot that signed a few of us up to about 200 mailing lists this morning. Not only do I trust Matthew's analysis (and was watching him go through the various steps on IRC as it happened), but then there were two other bits.

Ryan refused to approve two of my comments I made on his latest blog entry (more than happy to screenshot this). He claimed he too had been spammed, and had to abandon his email address of a few years. Even if you ignore the length of the text blanked out in the title bar not even remotely matching the length of his personal email address, there were only 131 messages in the inbox, of which 127 were unread, and no others but spam visible. He claimed they were archived; I offered to publicly apologise if he'd do a quick screencast showing him logging into that account and showing some messages from the archive to prove the point. Unfortunately he didn't bother approving these comments. (Incidentally, if you had to 'abandon' an email address due to an avalance of newsletters, et al, which took an hour or two to fully unsubscribe from, would you still bother blacking out the address everywhere?)

As per his standard 'insult everyone with random images from the internet and YouTube videos, then wildly claim conspiracies against him' policy, he went on to claim Matthew was conspiring against him, but given the choice between Matthew conspiring and severely irritating a few of his friends in the process, and some scorned 16-year old continuing his track record of acting like an irrational, immature idiot, I know which one I'd pick.

It takes some skill to be banned from all the Ubuntu IRC channels and the Ubuntu forums both, but I guess this morning showed that was completely justified. Apologies to everyone waiting on the announcement of sponsorship for XDS, as well as hotels, but unfortunately some people just can't conceive of having better things to do than acting like chavs. Hopefully IzanbardPrince/TheAlmightyCthulu/etc goes back to impersonating Kevin Carmony, flaming the bejesus out of companies using BIOSes which trip Linux bugs, and other, equally productive, uses of his time.

This is part 1 of a series on articles about the Firewire security issues mentioned below. For many years now, attacks via Firewire / i.LINK / IEEE 1394 have been a known security issue. Basically, if you gain physical access to a PC or laptop which has Firewire ports (or PCMCIA/Cardbus/ExpressCard, more on that later) you can

• read arbitrary RAM contents from the victim's system,
• overwrite arbitrary RAM contents with whatever you want,
• and perform many, many severe attacks based on the two issues above. Examples include grabbing a full RAM dump via Firewire (takes only a few minutes), grabbing ssh-agent keys, grabbing screen contents, modifying screen contents, bypassing login/password screens, and many, many more...

All of this is done by exploiting a "feature" of the Firewire spec (OHCI-1394) (PDF), namely that it allows read/write access to physical memory (via DMA) for external Firewire devices. Worse, as this is DMA, the CPU/OS will not even know what's going on. Even worse, this works regardless of whether you have locked your screen with a password-protected screensaver, or xlock, or vlock, or whatever. As long as the system is running, you're vulnerable. In this article, I intend to give a fairly complete overview of the available papers published on this issue, tools for testing the attacks, as well as mitigation techniques for various OSes. If I'm missing some important papers or tools, please post a comment! Papers, Attacks, and Tools Over the years a number of presentations and papers have been released with information about these Firewire issues. Maximilian Dornseif et. al. The first publication that I know of was done by Maximilian Dornseif, Michael Becher, and Christian Klein. They gave a number of talks on various security conferences on this topic:

• Pacsec 2004: 0wned by an iPod (PDF)
• 21C3: Hacking with Fire / Feuriges Hacken - Spa mit Firewire (PDF)
• Cansecwest 2005: Firewire: all your memory are belong to us (PDF)

They also released a number of tools, Firewire libraries for Mac OS X and Linux, as well as small demo scripts which use those libs:

• pyfw-20041111.tar.gz: Mac OS X Firewire bindings for Python, various demos
• http://c0re.23.nu/c0de/pyfw/: Other versions of the above code
• pyfw_linux.tar.gz: Linux Firewire bindings for Python (can be used with above demo code on Linux)
• ipod-linux-pyfw.tar.bz2: Instructions (+ disk image) on how to turn your iPod into a Firewire attack tool

Adam Boileau In 2006 Adam Boileau (a.k.a. Metlstorm) gave a talk called Hit by a Bus: Physical Access Attacks with Firewire (PDF) at Ruxcon 2006. In 2008 he then released a set of tools:

• pythonraw1394-1.0.tar.gz: Python bindings for libraw1394 (Linux). Tools: businfo, romtool, 1394memimage
• winlockpwn: Python script which can circumvent a locked Windows XP screen (an arbitrary password will log you in)
• bioskbsnarf: Grabs/shows the BIOS keyboard buffer via Firewire (which often contains your BIOS password)

Peter Panholzer As of early 2008 Peter Panholzer from sec-consult.com published a two-page whitepaper which says they were able to run a winlockpwn-like attack on Windows Vista via Firewire. There's not much information in the PDF unfortunately, and no tools were released, as far as I know.

• Whitepaper: Physical Security Attacks on Windows Vista (PDF)
• Bugtraq Thread about the whitepaper

David R. Piegdon The most recent toolset and papers I know of are from David R. Piegdon (a.k.a. IosTrace), who gave a number of talks in 2007/2008 about the issue, and also released a toolset called SEAT1394.

• 2007: OpenChaos: hacking in physically addressable memory (no extra slides)
• Easterhegg 2008: FireWire Hacking: paper (PDF), slides (PDF)
• More papers here...
• http://0null.net/software/SEAT1394/: tools and libraries for pyhsical memory access via Firewire/DMA: 1394csrtool, liblinear, libphysical, debug-sshkey, dump-memory, remote-ps, show-stack, snarf-sshkey, test-all-pagedirs, dmashell, ...

I'll go into much more detail on how the tools are used and what they can do in another follow-up article. Mitigation There are ways to eliminate or at least mitigate these attack vectors. The simplest and most secure way is to not have any Firewire ports installed (don't put Firewire PCI/PCIe cards in your PC, don't use Firewire PCMCIA/Cardbus/ExpressCard cards). Now, if you have a laptop with built-in Firewire ports, you have a problem, of course. In that case you could still physically destroy the port (by opening the laptop and cutting/desoldering stuff, or by putting glue/epoxy in the port in order to prevent any Firewire cables being attached). These are slightly drastic (but effective!) measures. Note: Even if you don't have any Firewire ports, you're not automatically safe and secure. If your laptop has a PCMCIA/Cardbus/ExpressCard slot, an attacker can simply insert a PCMCIA Firewire card (for instance) in that slot. Chances are, that your OS will automatically load the driver for that card and also the Firewire drivers you'll need if you want to use the card for attaching Firewire devices. Game over. Your "secure" laptop is now vulnerable... If you cannot (or don't want to) remove/destroy/disable your Firewire ports, the next best thing is to ensure that nobody except yourself ever gets physical access to your PC/laptop. This is hard to do for a PC, and almost impossible for a laptop, mind you. Finally, there are some software measures you can use to prevent at least physical DMA access for Firewire devices: Mitigation: Linux Pretty much every Linux system with the "old" Firewire drivers loaded (kernel module ohci1394 et. al.) is vulnerable to these issues. Newer kernels now also ship with a new Firewire stack called "juju" (kernel module firewire_ohci et. al.) which may or may not have the same issues (not fully tested by me so far, will report back later). Per default, all recent kernels, e.g. 2.6.26, are vulnerable, but see below. Under Linux, simply using a kernel which doesn't have any Firewire support (neither built-in, nor as a module) is the most secure option. If you must have Firewire support you can load the ohci1394 module with the phys_dma=0 parameter to at least disable physical DMA support:

  $ modprobe ohci1394 phys_dma=0

I have personally tested this on some boxes and I can confirm that it renders the currently published tools useless. As for the new "juju" Firewire stack, I'm not so sure. A few quick tests showed that the currently available tools don't work with the new stack, but you shouldn't feel too secure! AFAIK the new stack does support (or will support soon) physical DMA for Firewire, so it's probably just a matter of adapting the tools a bit (I'll do some testing/research on this later, as time permits). Mitigation: Mac OS On Mac OS you might also be able to completely remove Firewire support from the kernel (but I don't know if/how that can be done, not sure if you can easily recompile Mac OS kernels, and/or if you even have buildable source code and toolchains for that). However, you can at least remove the Firewire support in the default Mac OS installation by unloading AppleFWOHCI.kext:

  $ sudo kextunload /System/Library/Extensions/IOFireWireFamily.kext/Contents/PlugIns/AppleFWOHCI.kext

Thanks to a Daniel Reutter for letting me abuse his MacBook via Firewire and for finding the above kextunload command line. We have successfully tested that after unloading AppleFWOHCI.kext the current tools won't work anymore. The tests were done on a Mac OS X Tiger (I think) with all recent security updates applied. Please leave a comment if you can test other versions of Mac OS X... Mitigation: Windows As for Windows, well, I guess you're screwed. While Windows XP does implement sort of "protection" in that it only allows physical DMA access via Firewire to devices which "deserve it", e.g. iPods (or any other Firewire mass storage device, I guess) this can be easily defeated by having your attack PC/laptop pretend to be an iPod (see the romtool Python script by Adam Boileau). The only remaining option I know of (short of removing/destroying Firewire ports or preventing physical access alltogether) is to disable the Firewire ports/drivers in the device manager (untested by me so far). If you do that, remember to also disable all PCMCIA/Cardbus/ExpressCard controllers, of course (see above). So far I've tested Windows XP SP2/SP3 successfully with Adam Boileau's tools. I haven't yet been able to test Windows 95/98/Vista, if you can verify one of them, please leave a comment. Mitigation: OpenBSD/FreeBSD/NetBSD/OpenSolaris/... On OpenBSD you're likely not vulnerable as OpenBSD doesn't have any Firewire drivers at all, as far as I know ;-) As for FreeBSD, NetBSD, OpenSolaris, and other OSes I don't have any information. I might be able to test one or two of them in the nearer future, but please leave a comment if you have some information about whether they are vulnerable and/or how you can secure your system... Conclusion That's it for now. I hope you now have a good overview of these issues and how to protect. I can only urge you to take this problem seriously! Three or four minutes of leaving your laptop unattended are fully sufficient for an attacker to get a full forensic image of all your RAM contents for later analysis. This is at least as critical as the Cold Boot attacks, if not worse. I will follow-up with more articles about some more interesting details on these Firewire issues, how to use the above tools, and I'll report on some of the stuff I was able to find in RAM dumps gathered via Firewire...

Last weekend I updated the Debian package of MySQL to 5.0.67, the latest Community Edition release. It was not uploaded into the Debian archive, but is available from my home directory on gluck (amd64 only at the moment). The next Debian release lenny is frozen already, which means no newer upstream releases get accepted into testing before lenny is released, hence lenny definitely gets shipped with MySQL 5.0.51a. We will not see MySQL 5.0.67 or 5.1 in lenny, but we will continue providing backports of newer MySQL releases.

Our current primary goal regarding the MySQL packages in Debian is to get 5.0.51a in shape for lenny, so please do not send us mails asking about MySQL 5.1 or MySQL Cluster. When lenny got released we will upload MySQL 5.0.67 (or any newer community release) to unstable, and will then take care of MySQL 5.1 and MySQL Cluster.

When configuring servers the trade-offs between RAM and disk are well known. If your storage is a little slow then you can often alleviate the performance problems by installing more RAM for caching and to avoid swapping. If you have more than adequate disk IO capacity then you can over-commit memory and swap out the things that don’t get used much. One that often doesn’t get considered i the trade-off between RAM and CPU. I just migrated a server image from a machine with two P4 CPUs to a DomU on a machine with Opteron CPUs. The P4 system seemed lightly loaded (a maximum of 30% CPU time in use over any 5 minute period) so I figured that if two P4 CPUs are 30% busy then a single Opteron core should do the job. It seems that when running 32bit code, 30% of 2*3.0GHz P4 CPUs is close to the CPU power of one core of an Opteron 2352 (2.1GHz). I’m not sure whether this is due to hyper-threading actually doing some good or inefficiencies in running 32bit code on the Opteron - but the Opteron is not giving the performance I expected in this regard. Now having about 90% of the power of that CPU core in use might not be a problem, except that the load came in bursts. When a burst took the machine to 100% CPU power a server process kept forking off children to answer requests. As all the CPU power was being used it took a long time to answer queries (several seconds) so the queue started growing without end. Eventually there were enough processes running that all memory was used, the machine started thrashing, and eventually the kernel out of memory handler started killing things. I rebooted the DomU with two VCPUs (two Opteron cores) and there was no problem, performance was good, and because the load bursts last less than a minute the load average seems to stay below 1. It seems that the use of virtual machines increases the scope of this problem. The advantage of virtual machines is that you can add extra virtual hardware more easily (up to the limit of the physical hardware of course) - I could give the DomU in question 6 Opteron cores in a matter of minutes if it was necessary. The disadvantage is that the CPU use of other virtual machines can impact the operation. As there seems to be an exponential relationship between the number of CPU cores in a system and the overall price it’s not feasible to just put in 32 core Xen servers. While CPU power has generally been increasing faster than disk performance for a long time (at least the last 20 years) it seems that virtualisation provides a way of using a lot of that CPU power. It is possible to have a 1:1 mapping of real CPUs and VCPUs in the Xen DomU’s, if you were to install 8 DomU’s that each had one VCPU on a server with 8 cores then there would be no competition between DomUs for CPU time - but that would significantly increase the cost of running them (some ISPs offer this for a premium price). In this example, if I had a burst of load for the service in question at the same time as other DomUs were using a lot of CPU time (which is a possibility as the other DomUs are the clients for the service in question) then I might end up with the same problem in spite of having assigned two VCPUs to the DomU. The real solution is to configure the server to limit the number of children that it forks off, the limit can be high enough to guarantee 100% CPU use at times of peak load without being high enough to start swapping. I wonder how this goes with ISPs that offer Xen hosting. It seems that you would only need to have one customer who shares the same Xen server as you experiencing such a situation to cause enough disk IO to cripple the performance that you get.

Share This

Last month, the dutch-languaged C'T featured an article about retouching pictures with The Gimp, amongst others. Great timing, of course, since everyone goes on holiday during summer, right? Right. It's amazing what you can do with The Gimp and a bit of basic knowledge. Take this picture, for example, which I took at this year's FOSDEM: I kindof like it, but the colors are a bit blend. Too much of a red tint over everything. So, what we need to do, is change the curve: Pardon my, eh, Dutch. The trick is to remember that there are only so many colors which can be represented in a (JPEG) photo. The histogram on the background represents that; and by modifying the curve that is above the picture, you can effectively change the colorspace that is available for any peaks. If there's a lot of the darker blue in the picture, but less so in the lighter regions of the blue (as in this case), you just give the picture more space in the blue regions so that the blue that actually exists in the picture can be better represented. We do this by lowering the curve right before the peak, and by raising it afterwards, as the above screenshot shows. After doing so for red, green, and blue, this is the result: Looks much better, right? Way more contrast, and the colors look much more natural. And that only took me like 10 seconds to do. Do watch out, though -- it's easy to overshoot, resulting in an ugly picture; and you wouldn't necessarily want that. Also, if your camera has a RAW mode, you're going to be able to do a lot more of this kind of retouching with that than you would be using JPEG files. Then again, my camera has RAW too, but I don't use it most of the time...