Tuesday, May 10, 2011

Femtobuntu Progress Report

I've ported the script fully to 11.04. As expected, the KDE and *box segments required no modification, however (for some odd reason) you still get the generic Unity error on the first login (it never shows up again). Unity isn't in there yet, but I'm working on it. If you want to hop on the testing train, you can download the script from http://minimal-desktop.sublevel21.com/latest.sh. Remember if you're wget'ing this onto a new CLI install you'll have to manually switch to tty1.

Unity support is my priority right now, then Xfce after that. GNOME2/3 work fine (so far as I know).

Update: Whaaaaat? The KDE install boots to GNOME 2. I... don't even know what causes that. Investigating the crap out of this...

Wednesday, May 4, 2011

Roadblocks

Evidently Natty doesn't like a CLI install (from the 11.04 Alternate install disc). It refuses to boot! Let's hope the Netboot installation works.

Update: As dpeter pointed out, the CLI install fails to work inside the testing environment (as well as older machines). Until this is ironed out, I can't really work on the project effectively.

Le Second Update: esauvisky pointed out that tty switching still works. I hate to do it, but I guess I have to make the user handle tty switching in order to get to the script until this bug is fixed. Thanks, mate!

Update the Third: Installing GNOME forces the install of Unity. This needs to stop happening. I'm not even sure why, because none of the dependency trees map out that way. I think the default install of GDM is designed to kick to Unity, even when it's not even installed.

Update4: Or not! It's just stupid and gives me the standard "your hardware can't run Unity" message, despite Unity not being installed at all.

Tuesday, April 12, 2011

Advanced SSH Tunelling

In case you don't already know, ssh is kind of a big deal in the GNU/Linux world. It stands for "secure shell", and it's one of the primary ways of remote administration (or login in general). Apart from the standard use, one of my favorite uses of ssh is to create on-the-fly tunnels (or proxies).

This guide makes the following assumtions:

  • You own a Linux computer
  • Said computer's SSH port is forwarded
  • You have a basic understanding of the Linux command line
  • The client is running a POSIX-compliant OS with ssh installed
The basic syntax is as follows:
ssh -D 9999 user@ip.add.ress
Let's break that down a little. ssh is the command to create a secure shell session. The -D flag tells SSH to create a local tunnel (SOCKS5) on the specified port, in this case 9999. user is your username, and ip.add.ress is the IP address of your proxy server. You can retrieve this by running the command:
wget http://www.whatismyip.com/automation/n09230945.asp -O - -o /dev/null && echo
on the SSH server. (Note: the echo command is necessary because wget does not echo a newline at the end of its output.) In order to use this proxy that we've just set up, we need to configure our programs to use it. Most Web-based programs have proxy settings (for example, in Firefox they are found in Edit > Preferences... > Advanced > Network > Settings... In the "Server" or "Host" section, you would place localhost and in the Port section you would type 9999 (or whatever port you specified above). This will route all traffic through that server, through the secure connection that SSH provides.

In some cases, this is not enough. Let's say you have a remote computer running VNC and you don't have its ports forwarded. Is it possible to connect to that machine though your SSH server? The answer is a resounding "yes". It's more complicated, but entirely possible. The syntax would be:

ssh -L 9999:net.work.ip:5900 user@ip.add.ress
Instead of using the -D flag, we use the -L flag. This creates a direct proxy to a specific machine. As above, 9999 is the local port to create the tunnel on, user is your username on the SSH machine, and ip.add.ress is your external IP address. In the example above, 5900 is the port we want to connect to on the remote computer, and 5900 is the default VNC port. Replace this with what you need. net.work.ip is the local IP address of the final target machine. You can retrieve this by running the command:
ifconfig |grep inet |grep Bcast |cut -d ':' -f 2
on the target machine.

Let me know if there's anything else I can expand on.

Thursday, February 17, 2011

Planned downtime

The scripts and script generator (on minimal-desktop.sublevel21.com) will be offline for planned maintenance from 1:00 PM EST to approximately 2:30 PM EST. You can still download the scripts from Launchpad, Github, or Softpedia.

Thursday, February 10, 2011

Re-licensing the project

After much deliberation and research, I have decided to put my foot down and stop using the GNU Public License (GPL) for future releases of MDU. I understand that the terms of the GPL explicitly state that derivative works must be GPL'd, but I'm consciously breaking the terms of the license. Starting with the next version of MDU (most likely 11.04), the script will be licensed under the much more free (as in freedom) MIT license.

If anyone has a problem with the re-licensing, I invite you to take a look at the comparitave lengths of each license. The MIT license reads, "you may do whatever you want with this code." The GPL reads, "you may do whatever you want with this code, provided it does not use any non-free libraries and the derivative works must be licensed under the GPL." Yikes.

Sunday, January 30, 2011

Working with Big Patchsets

In the past, whenever there was a need for me to test or review huge patchsets, I'd generate individual patches by saving the mails containing them. This can get cumbersome, especially if the patchset is huge and if you have to try out multiple versions of the patches. There is however an alternative available. It is to obtain the mbox file pertaining to the entire patchset. The mbox file for kernel patches can be obtained from patchworks. The home page displays a list of projects that are hosted. Below are a few steps to get started -
  1. Create a login on patchworks
  2. Once in your account, select the project of interest from the home page
  3. Using the filters, search for the particular patchset
  4. Select the individual mails of the patchset and create a new 'bundle' from the interface at the bottom of the page. 'bundles' are a group of related
    patches. Name the bundle appropriately
  5. You can go to all your bundles by clicking on the 'bundles' link at the top right corner of any page
  6. The bundles interface allows you to manage your bundles, with support to download it. Bundles are nothing but all the mails in a mbox format
  7. You can then open the mbox with either your mail client or apply it directly to your tree with patch management tools that allow importing mbox files. I use mutt to read the mbox file and stgit to import the patches

Tuesday, January 18, 2011

Attobuntu Update 2

Not too much going on lately, but there have been some significant changes to the script.
  • Added support for Openbox and Blackbox
  • Improved choice tree for *box segment: Now has all of the choices of the other sections (minus CUPS)
  • Fixed the bug for rare moments when the script didn't terminate with a reboot
  • Fixed the k/ubuntu-restricted-extras lockup bug
I am looking into adding support for Xfce, LXDE, and Unity. These will probably be implemented in MDU 11.04 "Femtobuntu", due out on the 28th of April this year.

You can get 10.10.2 "Attobuntu Update 2" from the Launchpad, Github or my Personal Version Archive.