One afternoon, not so long ago, I received a phone call from one of our clients asking LightCube to investigate why a web application hosted on an internal Linux server was so unresponsive. After a little bit of poking around it became apparent what was happening: someone had managed to break into the system and create a rogue account for themselves and was using this account to continually attack other machines! How had this intruder gained access? One word: VNC.

Before I explain further how this happened, let’s step back for a second. Our client is a fairly large company, with skilled IT professionals managing their network infrastructure and services, mostly hailing from the Windows world. When they set about developing an internal web application, however, the low cost of Linux and Open Source was too attractive to ignore. So they grabbed a distro, set it up on a machine and got to work. Coming from a Windows world, the technicians incorrectly (but perhaps understandably) expected an item labeled “Remote Administration” would configure a service that behave like Windows Remote Desktop Connection. Instead, what they configured was a very insecure VNC service on a publicly available machine.

(As a sidenote, to me this well illustrates a very important point. The known stability, reliability and low-to-nil licensing cost of Open Source software means that a lot of people are looking to use it, and these days, basic services can be implemented fairly easily. However, getting secure, reliable, optimized use out of your Open Source still requires someone who knows what they’re doing.)

Back to the story, here’s what happened: One of their administrators logged in remotely to the machine through the VNC connection. As root. (That’s the first mistake, but I won’t really address that too much here. Keep in mind they’re coming from Windows, eh?) Then, when the administrator was done doing what he was doing, he simply closed the VNC window. In the Windows world, that wouldn’t be much of a problem. When connecting again, the Windows server would require that you authenticate. With VNC, not so much. Unless you log out of the remote system, whoever next comes and tries a VNC connection on the default ’0′ session – they get whatever you left open. If you were logged in as root, as was the case here, a full root desktop is what you get. “Come right inside, make yourself at home! Here’s the keys, change anything you like.”

Don’t misunderstand me. This isn’t a case of “Windows has better security than Linux”. I think someone would have a hard time arguing that point. This is a case of someone enabling an insecure protocol on a Linux system without really investigating how it works. To be fair, this particular distro did make it seem like this was a pretty standard way of remotely administering the machine. A little note from the distro about VNC being unencrypted and using poor session handling methods would have been more helpful, though.

We closed up the security holes on their system and ran a full audit. Fortunately, the damage was minimal. Afterwards, we needed to find an alternative for remote desktop management. What we found was NoMachine NX. All the communication takes place over an encrypted SSH connection, so it is secure (well, as secure as your password or public key, but that’s another article). But it’s also fast. NoMachine has taken a different approach to data transmission, such that it outperforms VNC any day. The server currently only runs on Linux or Solaris, but they have clients for all major desktops. If you absolutely must have a GUI running on your remote Linux server, I highly recommend NoMachine NX as a better way to achieve it.

Since its inception, LightCube Solutions has run on a custom-built Linux machine. Being a former LFS developer, I hail from the Linux world of ‘Do It Yourself’, and so I prefer to use self-configured servers, tuned and set exactly the way I like. This is no Fedora or Ubuntu where a host of unnecessary packages are forced on you and custom configuration files mask the generic and standard configuration files that come with the original software. This is ultimate flexibility.

But that flexibility does come at a price. Maintaining an LFS system can become a chore. Installing a new package always means compiling from source. Staying on top of security updates is entirely left to you. The system is only as good as your personal understanding of its internals. A balance somewhere in between would be ideal:

  1. A lightweight system that is known to be stable and secure.
  2. The possibility of complete configuration is given to the end user.
  3. The focus of the system is tight, and therefore higher quality (in terms of stability, functionality and reliability) can be achieved.
  4. All the while the system benefits from security updates and testing derived from a community of users and developers.

And so, having realized that I needed to move beyond my personal build scripts and start packaging the system (at the least, for my own sanity) it was decided to create a distribution based on our own needs for Linux-based web services. Voila! LightCube OS is born. The basic outline of the distro’s goals are this:

  • Provide a lightweight, fast, stable and secure LAMP application server.
  • As close as possible, adhere to the GNU principles of free software in the packaging and distribution of the system.
  • As nearly as possible, provide a ‘vanilla’ system. In other words, don’t create obscure custom configuration schemes. Allow as much manual configuration by the end users as possible.
  • Focus on packaging software that is reasonably used with production LAMP servers. (E.g., there’s no reason to build an X desktop environment for a server housed remotely and accessed mainly through ssh. Make the system geared towards advanced command line users. As much as a good GUI is nice, there’s no reason for a remote server to run one locally.)
  • Make the base system streamlined, optimized and small. While it is realistic to package a few variations of software (E.g., nano vs. vim, Exim vs. Postfix), the core system should focus on one basic set of core packages.

These are the main ideas behind LightCube OS. The build scripts and the core package specs are already under development. And the distro’s project site/infrastructure has been put in place: http://www.lightcubeos.org. Volunteers are welcome to join in the development.

In the meantime, what are your thoughts concerning the above? What advantages/disadvantages do you see to such a distribution? Do you have any comments or suggestions that will help improve its appeal or usability? I welcome your comments…

Usually I start these types of blogs with a decent disertation of what the problem was and then give the solution. Let’s flip that this time around since I’m in a quick blog mood.

Answer: ActiveCollab

Problem: Keep Reading.

When our clients and projects started to pile up we realized very quickly that we needed to get ourselves something that can give our clients exposure to our progress and help us manage our project. In my history of consulting that was done with multiple spreadsheets and project management software. Not wanting to go down that same path I started looking for SOMETHING that could be the best of all our wants and needs. Here was the raw list of wants and needs.

Needs:

  • Project portal that will allow our clients to see status reports
  • Tool that will allow us to collaborate with our clients without email chains, phone tag and IM convos
  • Location where files can be stored and information shared like a wiki but easy for a non-technical client to use
  • Web-Based and pleasing to the eyes
  • It needed to have strong User Access Control
  • Ticketing System is a must

Here are all the wants:

  • It would be great if it could be hosted on our own server
  • Wouldn’t it be great to customize it to look exactly the way you want?
  • Client portal feel without all that content management work

The solution as was previously stated is ActiveCollab. There were quite a few decent alternatives but AC really met all the requirements and then some. We have been able to customize it exactly the way we wanted and it works great. We are totally a LAMP stack shop and it was great being able to throw the code onto our sever and get it working and customized within a few short hours. Most importantly we have something that meets ALL of our needs and wants.

For more information check out: http://www.activecollab.com/

Since I wrote the post ‘Clonezilla‘ in January, our blog has been getting a lot of hits, apparently from people looking for advice on how to set up Clonezilla. This is understandable, since DRBL (of which Clonezilla is just a piece) is a complex piece of work, with loads of possibilities. So I decided to write up a small HOWTO, a quick and dirty method of getting Clonezilla up and running.

Before I go on, a bit of a disclaimer: Following the instructions below may not provide you with results that fit your particular needs. If you have specific and detailed requirements, see the DRBL documentation. If you would like to hire LightCube Solutions to provide assistance in setting up a Clonezilla solution for your organization, send an email to info@lightcubesolutions.com.

The Steps

1. Install Linux

You’ll need a Linux machine to run your Clonezilla services. These instructions were successfully tested on Ubuntu 9.04 and 9.10 and Debian 5. DRBL will also run on Fedora.

2. Install DRBL

First off, open up a Terminal. In Ubuntu and Debian, this is located in ‘Applications -> Accessories -> Terminal’. If you have sudo configured, you can change to super-user access by typing:

sudo -i

Otherwise, use the root password with the following:

su -

Next, add DRBL’s GPG key to your system:

wget http://drbl.sourceforge.net/GPG-KEY-DRBL
apt-key add GPG-KEY-DRBL

Update your apt configuration so that you can install software from the DRBL guys:

cp /etc/apt/sources.list{,.bak}
echo "deb http://drbl.sourceforge.net/drbl-core drbl stable" \
  >> /etc/apt/sources.list

Finally, install DRBL:

apt-get update
apt-get install drbl

3. Configure a Network Alias

DRBL requires that you have two network interfaces. We can get around this by adding a virtual interface:

cat >> /etc/network/interfaces << "EOF"
auto eth0:1
iface eth0:1 inet static
   address 192.168.222.1
   netmask 255.255.255.0
EOF
ifup eth0:1

To verify that you have set up the alias properly, type:

ip addr show eth0 | grep eth0:1

You should see something like this:
inet 192.168.222.1/24 brd 192.168.222.255 scope global eth0:1

4. Configure Your New DRBL Server

Run the following two interactive commands (note that this will require an internet connection and may take some time):

/opt/drbl/sbin/drblsrv -i
/opt/drbl/sbin/drblpush -i

Congratulations! That’s it, you have a DRBL/Clonezilla server ready to create and deploy custom images. All you need to do to start cloning is run:

/opt/drbl/sbin/dcs

Then, boot up your client machines using PXE. See, that wasn’t too painful…

If you have a Unix or Linux background, scripting should be second nature to you. Even ‘Windows Gurus’ usually do some little bit of automation with custom scripts. The power and flexibility that comes with the command line is hard to ignore, once you’ve tasted it. Still, those who have tasted both a Unix-type shell and the Windows command line will generally agree, Unix has the advantage here.

Although there are ways to do in Windows some of the things possible with Unix tools, it’s quite a bit more cumbersome. By taking advantage of Cygwin, you can bring that power and flexibility to Windows. A simple example of how I have used Cygwin alongside Windows tools involves Active Directory user creation, deletion and modification. The tools provided in Cygwin allow you to do advanced pattern matching and generate a list of users, file paths, etc., and then using the Bash shell, it is simple to create the logic necessary to call the Windows command line tools for modification of Active Directory. With the arsenal of useful tools that become available to Windows by using Cygwin, the possibilities for better automation grow considerably.

The Advanced Bash-Scripting Guide offers a great starting place for increasing your ability to write useful and powerful scripts.

No blog of mine would be complete without a reference of some sort to Linux From Scratch. If you’ve never heard of it before, Linux From Scratch (LFS) is an online community that produces a book containing instructions on how to create your own complete, functioning and customized Linux system by hand. As you follow the instructions in the book, you compile all the software from source code and manually create nearly every configuration file within your system.

Apart from creating a lightweight, reasonably secure, custom system and the pride of knowing that you made it all happen, as you go through the book you also get a good picture of what makes a Linux system tick.

Personally, because of the LFS project, my abilities in shell scripting and the Unix command line increased dramatically. This, in turn, led to my being able to contribute back to the project. I initiated the LFS LiveCD subproject, created and introduced to the community a program called jhalfs that automates the LFS building process (it has since been revised by a few talented individuals), and even helped develop the actual LFS book (a copy with some personal changes lives here). It was a fun ride.

LFS continues to receive good reviews as there appears to be many who enjoy the experience of customizing completely their own personal Linux system. Here’s a recent article that contains a fairly thorough review. The section on LFS begins on page 3.

In my first post (Light it up!), I mentioned that LightCube Solutions has an opportunity to pioneer an open source courseware application. Here are a few more details:
In a nutshell, the idea is to create a web application (at the moment it is powered by PHP and MySQL) that allows High School students to study content on their school’s intranet. Teachers will have access to add/create content and publish tests. When the students take the test, their scores are recorded in their profile. Teachers and other administrators can monitor their progress, scores, course history and so on. We want to keep it open source to allow a wider scope of input and collaboration.

Currently, the project is being organized here: http://www.lightcubesolutions.com/ScribbleAppTrac/
And a demo of the current code is here: http://www.lightcubesolutions.com/ScribbleApp/
The name of the project is likely to change, so stay tuned for more info.
JH

If you’re a system admin, charged with deploying workstations, likely you have need of a cloning system. In the Windows world, that system is predominantly Symantec Ghost. Perhaps you’re like me and have noticed how much a pain in the backside Ghost is. Specifically, it can be difficult to set up a bootable image with the right network drivers for your hardware. Also, Ghost is notorious at hanging when one client fails to participate properly in the multicast deployment.

In walks DRBL (Diskless Remote Boot in Linux). Essentially, DRBL allows you to remotely boot an entire Linux OS across the network. The useful possibilities that offers are quite extensive. But the use I’m highlighting here is what DRBL calls “Clonezilla”. Using open source NTFS tools, DRBL in Clonezilla mode allows you to take a snapshot of a partition or entire disk and then multicast that out to many clients. The advantage of doing this in Linux is the modularity of its kernel and support for a wide range of hardware, all in one easily distributable system.

It can take a bit of skill to get DRBL set up correctly, but once you do, the advantages over such a narrow and closed piece of software as Ghost make the effort well worthwhile.


JH