Archive for category observations
How to move panels in Gnome 2.28
Posted by stephan in Technology, foss, free software, gsoc, observations on November 4, 2009
I just installed Ubuntu Karmic Koala on my workstation and came across the problem of not being able to move/drag Gnome panels around in order to have the panels on my primary monitor.
On the Debian system that was powering the workstation before this was a non-issue as I could simply click, hold and drag both the upper and the lower panel, but this didn’t work.
So, after a few minutes of googling I came across an entry at answers.launchpad.net[0] and a blog post, but I cannot seem to remember the URL to that one. I can imagine that some of you might be having the exact same problem, so the solution is holding down the ALT, whilst dragging as usual.
[0] https://answers.launchpad.net/ubuntu/+source/gnome-panel/+question/264
Problems running PHP as a separate FastCGI process
Posted by stephan in Technology, observations, sysadmin on April 1, 2009
As some of you might have noticed this webserver has not been that responsive in the past few hours and I have been working hard on getting that fixed. I finally identified the problem and was able to fix it.
The root of the problem was my setup running PHP as a separate FastCGI process. Unfortunatly it seems as if PHP can only handle 500 requests per FastCGI process and then seems to lock up.
The old setup of this site didn’t cause such problems and it seems the problem lies in not setting the PHP_FCGI_CHILDREN and PHP_FCGI_MAX_REQUESTS environment variables with the new setup.
How using proprietary software can affect system security
Posted by stephan in Technology, foss, free software, observations on March 29, 2009
There has been a lot of discussion on whether Free Software is more secure than proprietary software, but I have an additional argument that shows how the use of Free Software can improve system security.
Now you probably expect me to come up with a pure technical reason showing superiority of Free Software, but I am taking another path this time: let’s talk about user trust.
A possible attack – what to do about this?
Posted by stephan in observations, personal on March 26, 2009
Just as I wanted to start writing an article here and I entered the URL of this blog into my browser I got no response from the webserver, zero, nothing.
First I thought the PHP fastcgi process for this virtual host died, but a quick check on another virtual host suggested that something else was going on.
So I guessed the lighttpd process itself must be experiencing problems of some sort, but after doing a “netstat -nat” I knew what was going on:
tcp6 1 1 83.65.62.72:80 61.135.190.248:12474 LAST_ACK
tcp6 1 1 83.65.62.72:80 61.135.190.234:39671 LAST_ACK
tcp6 1 1 83.65.62.72:80 61.135.190.253:39211 LAST_ACK
tcp6 1 1 83.65.62.72:80 61.135.190.234:55160 LAST_ACK
tcp6 1 1 83.65.62.72:80 61.135.190.230:25836 LAST_ACK
tcp6 1 1 83.65.62.72:80 61.135.190.231:16865 LAST_ACK
tcp6 1 1 83.65.62.72:80 61.135.190.232:24266 LAST_ACK
tcp6 1 1 83.65.62.72:80 61.135.190.240:38441 LAST_ACK
tcp6 1 1 83.65.62.72:80 61.135.190.243:17726 LAST_ACK
tcp6 1 1 83.65.62.72:80 61.135.190.241:38206 LAST_ACK
tcp6 1 1 83.65.62.72:80 61.135.190.251:23892 LAST_ACK
tcp6 1 1 83.65.62.72:80 61.135.190.225:29675 LAST_ACK
Plus “a few” more of those. Now I’m not entirely sure whether it’s just some systems misbehaving or actually an attack, but my feelings told me this could have been intentional after all.
I did a quick whois on one of those IP addresses and came up with the 61.135.0.0/16 network which is owned by China Network Communications Group Corporation.
As the connections were made from pretty much every host in that network I had two choices: sit it out or block it.
I came to the conclusion that blocking the entire subnet from connecting to this system, at least temporarily, might be a viable solution and so I did.
However, afterwards I am asking myself whether I really had to block an entire 16-Bit network, so I am asking you: how do you handle such situations usually?
Autoconf and Python: checking for modules
Posted by stephan in foss, free software, nwu, observations on August 31, 2008
I am currently writing a Python application that makes use of GNU Autotools as build system and noticed that determining whether a specific Python module is installed is not that easy and no usable Autoconf macro exists. So I came up with my own solution, which I would like to share with you.
The AC_CHECK_PYTHON_MODULE macro takes two arguments: The module name and optionally the variable name holding version information. This way it is not only possible to determine whether a module is installed (ie. loads in Python) on the current system, but also retrieve version information from that module.
The following examples checks whether the Crypto module is installed and retrieves its version information from Crypto.__version__:
AC_CHECK_PYTHON_MODULE(Crypto, __version__)
The macro itself does never report and error, but rather only a found/not found result. Error checking is up to the user and can be done via these two Autoconf variables:
- PYTHON_<MODULE_NAME>
- PYTHON_<MODULE_NAME>_VERSION
PYTHON_<MODULE_NAME> is set to “1″ if the module is present and “0″ if not present.
PYTHON_<MODULE_NAME>_VERSION is only set when the version variable argument has been set and contains the version information of the module, if the module been found. If the module is not present this variable is also set to “0″.
The version variable argument is optional as I wrote, so the following invocation works too and only checks whether the distutils module is present:
AC_CHECK_PYTHON_MODULE(distutils)
As I wrote earlier in this article I would like to share this macro with you. You can download it here.
Is trying to fix (E)SMTP really worth it? [part 2 - infrastructure]
Posted by stephan in Technology, observations on July 3, 2008
[digg=http://digg.com/security/Is_trying_to_fix_E_SMTP_really_worth_it_part_2]This article is the second in my series about the flaws of (E)SMTP, the whole Internet mail infrastructure and how it could possibly be fixed. The main focus of this part is a new approach to the infrastructure which should help making emailing more secure, reliable and less spam-prone.
The first article can be found here and points out flaws and problems in the current systems.
Why are hardware manufacturers keeping specs to themselves?
Posted by stephan in Technology, foss, free software, observations on April 6, 2008
This is one question I have been interested in ever since I started using GNU/Linux.
Just think about it for a moment. About 20 years ago you got specifications for pretty much every piece of hardware you bought. You were given exact instructions on how to use the hardware you just bought, not only how to install it. Things have changed since then.
If you buy any piece of hardware today you actually have to expect not to get any documentation on how to “talk” to your new toy. You are only given a CD (sometimes even only a link to a homepage) containing drivers for a few specific operating systems, usually only Microsoft Windows.
Now I am no driver hacker and so I probably wouldn’t be able to implement a driver for anything on my own anyways, but the Free Software community would largely benefit from hardware documentation, as there are a lot of capable driver hackers out there.
This is not a problem that only affects the Free Software community though. There are a lot of pieces of hardware which do not work on recent proprietary operating systems anymore due to lack of support by its manufacturers.
At least this problem would not exist for Free Software operating systems, such as GNU/Linux, if hardware makers would publish documentation of their hardware. The people still using devices which are well beyond their end-of-life could implement drivers on their own, not being dependent on anyone.
What I am really wondering about in this case is why hardware companies are unable to coin standards for accessing devices of the same class. It works perfectly well for USB (take USB mass storage devices as an example) and I do not understand why there can’t be standardized interfaces to other hardware, such as network adapters, as well. On a very-low level these standardized interfaces do work. Just think of PCI, PCI Express or AGP.
Actually, if you think about this for a few more seconds you should realize one thing: Having standardized interfaces for devices of the same class would cut a lot of costs for hardware makers. Why? Oh well, if they design a brand new networking chip and still implement the given standard there would be no need of writing a new driver. Wait, there would be no need for per-device drivers at all. Implementing a common driver that accesses the standardized interface would be enough, for a whole range of devices.
So what am I asking of hardware makers? I would love to see companies creating devices of the same class to get together, create standardized interfaces, publish them and implement them in their new devices.
I know, this is not likely to happen anytime soon, so a more realistic approach is asking for Free Software drivers and/or documentation.
Personally I have stopped buying hardware which “works” with GNU/Linux, I have come to the point where I try only to buy hardware which either comes with Free Software drivers from the manufacturer or documentation which allows implementation of Free Software drivers.
This is probably the best way of showing these companies what you demand: Freedom.
Is trying to fix (E)SMTP really worth it? [part 1]
Posted by stephan in Technology, observations on March 27, 2008
[digg=http://digg.com/security/Is_trying_to_fix_E_SMTP_really_worth_it_part_1]
This one question has been in my mind for quite some time already. I mean, everyone uses SMTP (knowingly or not) when sending out emails and everyone sending emails also knows what SPAM is and receives SPAM messages.
However, few know how old SMTP actually is, and that, even though it serves everyone well, it has been designed in a time when everyone was thinking of Spam as canned meat. Back in 1982 SMTP was a great achievement and a lot of kudos should go to its creators, but now, in 2008, SMTP has become more of a liability than a great tool.
Originally, I wanted to write a single article covering all shortcomings of SMTP and possible solutions to these problems, but while writing the article a lot of text came up, so this is the first of two articles I am going to write on this topic. The first part is about the problems with SMTP and how fix-ups for SMTP are, even though they do work to some extent, a proper solutions to today’s issues.
Due to the way SMTP was designed and the way the Internet was back then it is prone to various things, like SPAM messages, sender spoofing, data manipulation and so forth. A few attempts have been made at fixing some of the shortcomings of SMTP, like ESMTPA (SMTP-AUTH) or SPF, Callback Verification, and DKIM, but none of them has really fixed all problems that exist and all of these modifications are in my opinion mere workarounds. Let us have a look at why both SPF and DKIM fail to fix the all problems SMTP has right now.
Less spam again
Posted by stephan in observations, personal on March 26, 2008
I found a solution to the problem last described in this article.
To sum the problem I was experiencing up: My anti-spam system (namely Spamassassin) did not detect spam mails anymore.
Now here is the reason it did not: After some more investigation of the problem I noticed that spam emails were received via a local connection (forwarded from fetchmail). However, one of my Exim ACLs says not to scan emails from localhost for spam.
So, the solution might be a hack, but it worked out perfectly. Starting fetchmail with the -S <servername> argument causes it to send emails to the given SMTP server rather than localhost. Using the real hostname of my server caused the “do not scan local mails” not to kick in and all mails received via fetchmail to be scanned again.
Problem fixed.
Mails from Technorati not arriving: not obeying their own SPF rules
Posted by stephan in observations on March 25, 2008
As I was looking into problems with my mail server I noticed one more thing: I was wondering why I did not receive password recovery emails from Technorati. It seems as if they are not obeying their own SPF rules:
2008-03-25 14:46:23 H=nat-365m.technorati.com (t120.technorati.com) [208.66.64.4] F= rejected RCPT : Not authorized by SPF
Now I am wondering why someone sets up SPF for his mail domain when he is in fact sending emails from other IP addresses as well. Time to update your SPF rules Technorati…
