The Buffalo Linkstation Live (v2) - Unbricking

I just managed to get my Buffalo Linkstation (running Debian based Freelink) to brick in a new way: it would pull the kernel and initrd by tftp over and over again or it would appear to have loaded them but simply stop.

After trawling the forums I have salvaged the situation by mounting the HDD on a linux system and erasing and rebuilding the default /dev/sda1 partition.

I have also recorded how to do it in the relevant wiki article like a good boy:

http://buffalo.nas-central.org/wiki/Revive_your_arm9_box_from_scratch#Troubleshooting

Linkstations and similar Linux based NAS devices make fantastic home servers - mine draws ~13W under load providing daap, DHCP, NTP, apache, NFS, samba and AFS. Beats the hell out of an always on home Intel server.

How can I allow users to run a script as root?

I am glad you asked me that question!

In this case I need a user to nuke a process related to themself but executing as 'nx'. So to kill it they would have to be root (or nx). Killing the process and the related cleanup requires a script to automate it so I need to make a script run as root.

I can do that by making the scripting language interpreter (e.g. perl, python, etc) always run as root ("setuid"). This means that all scripts executed by that interpreter run as root.... oops. Ok bad idea as anyone can run any script they write as root. I know, I shall make the kill command always run as root. Anyone can now kill any process .... oops. Ok bad idea, slightly less a security risk though.

The solution to the above class of problems is called a 'shim' after small bits of metal. Go look the reference up if you care. The solution is make a tiny C program that when executed by a user runs as root ("setuid") and then executes the script, sanitising and passing any necessary arguments.

So here is a trivial C program to execute a single script (nxclean.c):

#define PATH "/usr/local/sbin/nxclean"
#define BUF_SIZE 10000

#include <stdio.h>
#include <unistd.h>
#include <sys.h>

int main(void)
{
uid_t user;
char user_str[BUF_SIZE] = {'\0'};

//      printf("My UID is: %d\n", getuid());
//      printf("My EUID is: %d\n", geteuid());
user = getuid();
snprintf(user_str, BUF_SIZE, "%d", user);
//      printf("My UID is: %s\n", user_str);
setuid(geteuid());
//      printf("My UID now is: %d\n", getuid());

execl(PATH, PATH, user_str, (char *) 0);
}

So what is going on here? Firstly a couple of #DEFINE's to save typing. Note that the buffer sizing and the initialisation of the whole buffer to '\0'. Remember this is a program that is going to run as root. It takes no command line arguments, simplifying things, but it is taking things from the underlying OS so be sure to be safe. If you are taking command line arguments then check them every which way, run regex's, size checks, the works. Otherwise kiss your security goodbye.

In this case it stores the UID of the current user as it needs it later, makes itself root via the setuid(geteuid()); line and then executes the script (now as root) passing arguments created from the UID collected earlier.

Note this only works if you have set the little executable this compiles into to run as root. Google "setuid".

DATE09 TPC finished and went well - linksys WRT54GLs are awesome!

Arrived at the IET on the evening of Wednesday with my team this week and immediately got the benefit of the IET's professional staff. Within 1 hour I had the server running a custom software package crafted specifically for DATE to manage the submissions.

Imagine trying to manage 900 submissions on paper + email? Impossible.

In the initial hour I also deployed 4 wifi routers, all linksys WRT54GL's to manage the 190 members who review the papers in groups organised by topics.

On Thursday under peak load the WRT54GL's were handling 43 WPA encrypted connections simultaneously (note that the SPI was disabled and also note a CPU monitor would be very helpful to gauge the CPU load).

They worked all day with only 5 laptops unable to connect, and considering the fact that wifi with encryption isn't a very well adhered to standard (lots of bugs) that is just noise. Even that was resolved with a driver update to a 2200BG card from Intel.

It all had to work, and it all came together.

Synopsys Babbage Grant Proposal In!

It has been a most incredible slog getting the grant proposal out of the door. But now it is all done and I am really thankful. DATE2008 TPC here I come.

The love affair with freenx is over.... time to make the marriage work

It seems that not much survives contact with students!

Basically if the freenx session isn't correctly terminated or established then desktop processes and a nx process are left running to the server which will prevent them logging in again.

However I am not the first person to notice this:

PSI Labs who use the technology have developed a RPM of scripts to manage this properly called nxcleanup. A user session has the standard number of processes for the desktop however there is an associated nx process that the student doesn't own. So the script nxclean would need to be run as root.

How do I enable a student to run a script as root that wipes out processes of an arbitary user?

Simple: Use a setuid "shim"! Write a trivial C program that takes no inputs (or has very, very thorough sanity checking!) which identifies the current user using posix calls and then exec's the script after passing it the current username. Nifty eh? This is a standard way of making scripts run safely as root. I'll post it as soon as I am done.

NX Technology Makes Remote X Possible

I implemented NX technology on our linux CAD servers some time ago.

NX has enabled a whole distance learning class from America using some really poorly coded CAD tools (some are windows GUIs run under emulation).

It made it like using them over the LAN!

If you have remote UNIX application needs then please consider this technology.

I am more than happy to consult on your CAD architectures.

AVR Studio and WinAVR as C teaching tools...

AVR Studio when run in combination with WinAVR (packaging avr gcc, avr-libc and all the other gubbins) provides an awesome 1st learning environment for people learning C for the first time

• Completely free, for students and staff
  
• Traffic light graphical message highlights: Green spots next to messages when things went right, yellow for warnings and red for errors. Instantly understandable!
• Graphical indication of the current location in the program with autostep to move step by step through the program - outlines the flow immediately.
• Processor window showing the program counter, cycle counter (how much time has your program taken?). Turning ints to floats added 4000 cycles to a simple test program.
• Internal processor registers very visible
• I/O View graphically highlights ports and pins with a row of 8 squares which are filled when the bit is set. Instant graphical Hex to Binary

I really think that this is an ideal learning environment, not too big and not too small.