|
|
Categories » ‘Administration’
July 28th, 2010 by Peter
6 years (!) after my initial Debian ITP (see here) and all the hard work on a custom Condor Debian package, they finally made it too:
http://www.cs.wisc.edu/condor/debian/
The Condor people are now offering there own Debian repository for the (longer existing) Condor DEB files. This allows you to have a decently updated Debian-based cluster with the latest version available. Great thing. Use it.
If you were using my Condor Debian packages in the past, you should stop that, and do a careful migration. The user names are equal, and the Wisconsin version of the installation scripts seems to be a little bit picky. I recommend to purge my package (for example with apt-get remove –purge condor) and check for any remainings, before you start with the new repository.
The installation is by default working in personal mode, which demands no user interaction during installation. The package looks like a completely new development, which is sad – some people (check the ITP) spend some time on things such as debconf support.
February 24th, 2009 by Peter
For some measurement task, we needed to isolate one CPU core on an Intel Quad Core machine under Linux 2.6. With the background of SMP and NUMA system support, Linux provides the following options:
- isolcpus=[]: This is an old kernel boot parameter, which allows the isolate one or more CPU’s from the scheduler. Processes can still be placed on this processors by explicit affinity system calls. Processors are still utilized for interrupt processing, since they are only taken away from the OS scheduler. Modern kernels implement this feature with the (anyway given) scheduling domain support, a part of the cpu sets functionality. The kernel boot option was therefore lately requested to be removed.
- CPU sets: CPU sets constrain the CPU and Memory placement of tasks to only the resources within a tasks current set. Specifically, the sched_setaffinity() and the mbind() system calls are accordingly intercepted. The scheduler has also support to partition the system CPU’s into a number of scheduling domains. By default, there is one scheduling domain covering all CPUs, except those marked with isolcpus (see above). After mounting the according device, you can create custom CPU sets and assign tasks and processors to it. In our experiments, it was not possible to remove a core from the default CPU set. Aquick check of the sources showed that this is intentional, even though the error code is misleading:
mount -t cgroup -o cpuset cpuset /dev/cpuset
root@intel:/dev/cpuset# cat cpuset.cpus
0-3
root@intel:/dev/cpuset# /bin/echo 0,1,2 > cpuset.cpus
/bin/echo: Schreibfehler: Keine Berechtigung
- CPU hotplug: The CPU hotplug implementation provides exhaustive support for CPU management within the SYSFS file system tree. The implementation also frees the CPU from interrupts and timers. A simple echo 0 > /sys/devices/system/cpu/cpuX/online puts the particular CPU off-line. With a very recent kernel, it also works for single cores in our system:
root@intel:/sys/devices/system/cpu/cpu0# ls -l
drwxr-xr-x 5 root root 0 24. Feb 18:59 cache
drwxr-xr-x 4 root root 0 24. Feb 18:59 cpufreq
drwxr-xr-x 2 root root 0 24. Feb 18:59 microcode
drwxr-xr-x 2 root root 0 24. Feb 18:59 thermal_throttle
drwxr-xr-x 2 root root 0 24. Feb 18:59 topology
If you want to check if your disabling activity was successful, check the output of /proc/interrupts.
January 12th, 2009 by Peter
A presentation at the CCC 2008 congress showed how to create a rogue CA certificate, based on the well-known flaws in the MD-5 hashing algorithm. There is also an exhaustive explanation on the web. Verisign already reacted and switched to SHA-1. For students it might be interesting to see that a very basic crypto algorithm flaw can possibly harm a whole Internet security infrastructure. What happens if SHA-1 is broken tomorrow ?
September 8th, 2008 by Peter
A nice article about the underlying rules of peering and transit fees in the Internet autonomous systems (AS). If you ever wanted know why your HTTP request for the local newspaper home page travels through New York, here is the answer:
http://arstechnica.com/guides/other/peering-and-transit.ars
August 27th, 2008 by Peter
Security of distributed systems becomes more interesting again. The ancient Internet technologies more and more show their architectural weaknesses. I recommend every serious computer science student to understand the recent problems with BGP (here and here, or better here) and DNS (here, or better here). This is the stuff you have to deal with in the future of the Internet (and no, IPv6 is not a solution).
May 28th, 2008 by Peter
Things become complicated with this issue.
I recently posted some warning about the Debian SSH / SSL vulnerability, even before Heise had a clue  People now start to get hyperactive, which leads to a confusing amount of blacklists and guides on the Web.
For our Debian systems, I performed the following steps. Please note that the blacklist packages currently only check 1024bit and 2048bit keys.
- Update your SSH installation on all machines, in order to get “ssh-vulnkey” for free. The SSH server will reject all vulnerable keys from this point, so make sure that you keep some shell open. Use the following command to scan the complete disc for vulnerable SSH keys:
find / \( -name "*_dsa*" -o -name "*_rsa*" \) -type f -exec ssh-vulnkey '{}' \; 2> /dev/null|grep COMPROMISED
- Install the Debian OpenSSL blacklist package from the Debian Wiki. You can then check the disc for vulnerable SSL keys with a similar command:
find / -name "*.pem" -type f -exec openssl-vulnkey '{}' \; 2> /dev/null|grep COMPROMISED
This step can get a little bit annoying, since the openssl package asks for the passphrase of encrypted PEM files.
May 27th, 2008 by Peter
Since this afternoon, the internal Hetzner DNS servers seem to have a problem. You can connect, but get no answer. This is tricky since all basic services rely on DNS during their operation. Think of the reverse lookup during SSL negotation or the host name HELO check in the mail server.
For this night, OpenDNS saved me. The response times “feel” pretty fast, and I couldn’t find any problems reports from users regarding their advertisement and blocking policy.
However, the automated redirection features of OpenDNS for Web browsers might confuse your daemons:
frodo:~# ping foo
PING foo.nclmail.de (208.69.34.132) 56(84) bytes of data.
64 bytes from hit-nxdomain.opendns.com (208.69.34.132): icmp_seq=1 ttl=56 time=21.2 ms
64 bytes from hit-nxdomain.opendns.com (208.69.34.132): icmp_seq=2 ttl=56 time=20.3 ms
64 bytes from hit-nxdomain.opendns.com (208.69.34.132): icmp_seq=3 ttl=56 time=20.5 ms
I recommend to have the usual safe guards of DNS configuration – a valid search mydomain1, mydomain2, ... string in resolv.conf and static entries for localhost and all critical infrastructure machines in your /etc/hosts file.
May 15th, 2008 by Peter
The Debian security team announced a vulnerability in the OpenSSL package, reasoned by a Debian-specific change of the original sources. It leads to a predictable number generator, which makes the key space for generated private keys (for SSL certificates or SSH key-based authentication) extremely small.
As the authors noted, this is extremely nasty. It influences not only all Debian installations since 2006, but also all derived distributions such as Ubuntu or Knoppix. Whenever one of your applications is offering SSL-based security (mail server, web server, SSH server, OpenVPN, imap server, pop3 server, subversion, …), it could be vulnerable. If you got your SSL certificates from a provider such as GoDaddy or Verisign, they might be also vulnerable, even though you are not using Debian.
A wiki page tries to summarize the needed steps for all relevant packages.
I am currently investigating the already published scanner tools from MetaSploit. The page also contains a good explanation of the attacks nature.
[Update]
Save your time. Debian already provides a package with all possible weak keys, and a tool to compare this database with the keys on your system (“ssh-vulnkeys -a”). So just update your Debian as usual, and inform your users about the new SSH host keys.
Hagen had the best comment on that:
March 26th, 2008 by Peter
According to the usual news sites (e.g. Slashdot), the old ORDB spam blacklist (closed in 2006) now returns false positives for all queries. This is rather nasty, since mail systems still using it now mark all checked mails as spam. Depending on the configuration, this either rejects or at least sorts out all incoming mails. This does not only relate to mail servers, but also to all kind of client-side spam filter plugins and tools. Old versions of Spamassassin are a good candidate.
The Heise article explains that this is intended as some kind of wakeup call, in order to reduce the still high amount of useless queries. Deleting the domain is argued to be a non-valid solution, since the load then goes to the .org name servers. This is really the strange part of the argumentation, since it completely ignores the DNS negative response caching mechanisms (see RFC 1034, section 4.3.4, and RFC 2308, or here). They are part of Bind since 1996.
February 29th, 2008 by Peter
InfoQ had an interesting article on the recent outage of Amazons storage service S3. The article indirectly gives a beginners lecture on fault tolerance metrics, and gives an insight on the true relevance of SLA in practice. We learn again that even with a new term for distributed computing (“cloud”), the problems remain the same:
http://www.infoq.com/news/2008/02/s3-outage-trust-slas
[Update]
I start to feel a little sneak preview of old people’s wisdom. See here:
There is nothing new about the failures themselves, it is more about the (misplaced) trust on the vendors capabilities for dependability. Dependable systems cost real money – a lot of it. The old rule still counts – you get what you pay for.
|
|
|