So in IRC I brought up the idea of a web dashboard for managing a network of pkgsrc servers and liked it so much I started a google code project for it.

http://code.google.com/p/pkgsrc-dashboard/

If you're a pkgsrc/netbsd person and have some input, ideas, or want to join the project then let me know!

Labels: NetBSD, pkgsrc

I use blogger.com for this blog and on multiple occasions it has published empty rss.xml and atom.xml files. This is very, very annoying!

According to it's been fixed, but as of 2009/03/28, it hasn't!

Labels: google

Normally I would do a whole How-To on this topic, but it was so easy that it really only qualifies as a blog post. Everything pretty much just works on my eeepc 701 so there isn't a whole lot to document. The main accomplishment was just figuring out how to turn off the screen.

I'm mostly using the GENERIC kernel with the following line added:

i915drm* at vga? # Intel i915, i945 DRM driver


My xorg.conf came from X -configure. I can't remember making any changes to it, but here are some snippets:

Section "InputDevice"
Identifier "Mouse0"
Driver "mouse"
Option "Protocol" "wsmouse"
Option "Device" "/dev/wsmouse"
Option "ZAxisMapping" "4 5 6 7"
EndSection

Section "Device"
Identifier "Card0"
Driver "intel"
VendorName "Intel Corporation"
BoardName "Mobile 915GM/GMS/910GML Express Graphics Controller"
BusID "PCI:0:2:0"
EndSection


To turn off the LCD backlight and get a completely dark screen:

startx
xset +dpms
xset dpms force suspend


The only problem is that you must be in X for that to work. I would like to simply leave it on the console, but I couldn't figure out a way to turn off the LCD with screenblank(1) using wscons, and I feel like vesa might have some options, but I couldn't find them.

Labels: NetBSD

Jibbed The NetBSD livecd has been updated to a new version.

Labels: NetBSD

Okay, so an email came through the mailing lists recently about systrace being removed and how to handle it. This got me thinking about kauth and secmodel. Two ideas came to mind:

1) Implement system calls as a kauth scope.
2) Create a tool called secmodelctl which allowed for manipulation on an overlay level of the security model.

The main use for systrace to come back, in my opinion, is for great projects like sysjail.

secmodelctl should be like pfctl where you can load a config file, manipulate rules, etc.



<priv type="priveleged_port" action="add">
<prog>/usr/libexec/ftpd</prog>
<sha1>e34da0a32eda829b4496370cc24987322d2e852d</sha1>
<user>ftpd_user</user>
<port>21</port>
</priv>



Labels: NetBSD, project ideas

So someone I know recently forgot their password to a TrueCrypt volume and asked me to try getting into it. Obviously, I'm not much of a hacker but I wrote a little perl script to attempt a bunch of password iterations thought I would share some parts. The main thing to share is the list of arguments:

my $tc = "/Applications/TrueCrypt.app/Contents/MacOS/TrueCrypt";
my @tc_opt = ($tc, "--text", "--verbose", "--mount-options=ro", "--filesystem=none", "--non-interactive");

Then the more dynamic parts (obviously, pass needs to come from some kind of password dictionary or password-generating subroutine). @prog is the loop-local copy of @tc_opt.

push(@prog, "--password=\"$pass\"");
push(@prog, "$file");

Then the last bit:

my $strprog = join(" ", @prog);
system("$strprog");
if ( $? )
...


$? will be true on failure and false on success (1 vs 0) or you can get fancy and also test for negative values.

I was unable to recover the password because I didn't have enough information and I can only test one password/few seconds on my poor, slow computer, so a massive dictionary attack is out of the question, but if you're in the same boat this should get you started on the recovery.

Labels: perl programming

We had an interesting discussion on EFNet/#netbsd this morning about some possible enhancements to acpi and some other facilities being improved/introduced in NetBSD 5. The main idea was this: given a set of criteria, could netbsd automatically turn off hardware components to save on power?

So, for a simple example, if I have a server with two cpu's and my system load is less than 1 for an extended period of time, why not step down my cpu speed and if my load continues to stay low, turn off one cpu?

What if I never use more than half of my ram? Or what if my network traffic could go from gig to 100M without any harm?

I've worked in some power and cooling-starved datacenters where we would never seriously consider trying to set all of this stuff up, while at the same time we had a lot of standby servers, or very idle systems. This tells me that power management is probably seen as risky, difficult, or both.

All of this stuff, of course, also applies to laptops which need extended battery performance, lid-closing sleeps, etc. It's one of the few places where laptop-driven technology could make a big impact in a datacenter.

Anyway, netbsd isn't really there yet to provide a lot of this, but it seems to have facilities which could be put together to almost solve the problem:
powerd
drvctl
envstat
cpuctl

And maybe something more like sar or a similar dtrace-type listener.

Labels: NetBSD, project ideas

I wanted to give a little press to mk-configure by Aleksey Cheusov because I think it's an interesting project and because the auto tools are a regular source of heartache for developers and users. (you might know them as the standard ./configure && make && make install cycle)

Having a BSD-based alternative to these tools is nice for someone making BSD software and pushing the use of NetBSD's flavor of make is also cool because it's very powerful and could do a lot of things (like the above project shows) that are currently achieved with many different and difficult to understand/learn tools. Make is magic-enough. :)

Labels: NetBSD

Over the course of dealing with xml files, I've noticed one of the biggest complaint is the lack of simple tools to manage them. I don't mean special editors that make navigation/views easier, but things like grep and other really simple tools. (see some of the anti-plist discussions on netbsd mailing lists for examples of xml-hating)

My idea is for a tool that can perform simple greps and return a full record/line numbers/xpath, and also do some simple sed-type functions where you can change a single element in an existing file. Another neat function would, of course, be to define a template and fill out/append to an existing document, but the interfaces get complicated fast when you start to think about it.

So here are some possible interfaces to such a tool:
xmltool grep anystring/regex
xmltool grep -element string/regex
xmltool grep -attribute string/regex
xmltool grep -attributevalue string/regex
xmltool grep -data string/regex

xmltool replace... same stuff

Now, if only I could get my tiny mind around all of the xml libraries and write something as handy as this. :)

Labels: project ideas