|
How to install Ubuntu Linux on the decTOP SFF computer |
vote
 |
|
I recently bought a decTOP small form factor (SFF) computer. My goal was to build a cheap, fanless, quiet, and low power consumption Linux server. For $99 plus the cheapest available shipping, $40, my machine arrived 11 days after I placed the order. This is a tiny computer, about the size of a Mac Mini. But, because it has no fan, it runs a bit quieter and, with the help of a 1-watt, 366 MHz CPU, consumes only 8 watts. For comparison, the G4 Mac Mini consumes about 20-30 watts, depending on load. The decTOP comes with 128 MB of RAM in its sole SO-DIMM slot and a 10 GB 3.5 inch hard drive. I understand that it's a simple matter to replace the drive and to upgrade the memory to a maximum of 512MB. It also comes with no operating system and the ability to boot only from a USB drive. This article details the steps I used to build the USB boot/installation drive and install Ubuntu 6.06 on the decTOP. There is another article -- with additional decTOP links -- here on installing Ubuntu 6.06 on the decTOP with the aid of a Windows system. Fortunately ;), I run Mac OS X and Linux (Ubuntu 7.04), so that article didn't work for me. I did the installation of the Ubuntu 6.06 LTS Server Edition using my Ubuntu Linux box and a 1 GB USB flash drive -- although a 512 MB USB drive should work as well. - Download the Ubuntu 6.06 server ISO image from the Ubuntu download page. Depending on your plans for the decTOP, you might want to choose the desktop version. Unless you have already upgraded your decTOP's memory, however, you'll want to stick with the 6.06 releases.
- Install the mbr, mtools, and syslinux packages on the Linux system you'll be using to prepare the USB drive. If you run Ubuntu or some other Debian-derived system, the following commands may do the work for you.
apt-get install mbr
apt-get install mtools
apt-get install syslinux - Partition the USB drive with a single FAT-16 partition. I used the fdisk 'n' command to make the new primary partition 1. The fdisk 't' command can be used to change the partition type to FAT-16. My device name was /dev/sda.
fdisk /dev/sda - Make the FAT-16 partition the active partition. I used the fdisk 'a' command.
- Install a master boot record on the USB drive.
install-mbr /dev/sda - Install syslinux on the USB drive. Note that the USB drive should not be mounted when you do this.
syslinux -s /dev/sda1 - Create a mountpoint and mount the ubuntu ISO image using the loopback device.
mkdir /iso
mount -o loop -t iso9660 ubuntu.iso /iso - Create a mountpoint and mount the USB flash drive.
mkdir /usb
mount /dev/sda1 /usb - Copy the contents of the ISO image to the USB drive. This will take some time.
cd /iso
cp -r . /usb/ - Copy the /usb/dists/dapper directory into a new /usb/dists/stable directory.
cd /usb/dists/
cp -r dapper/* stable - Copy several files from /usb/install to the /usb root directory.
cp /usb/install/vmlinuz /usb/
cp /usb/install/mt86plus /usb/
cp /usb/install/initrd.gz /usb/ - Install the following text into a file named syslinux.cfg in the /usb root directory.
default vmlinuz
append initrd=initrd.gz ramdisk_size=24000 root=/dev/ram rw - Flush all writes, unmount, and remove the USB drive. After the sync step, wait for all of the data to be written to the USB drive.
sync;sync
umount /usb - Connect the ethernet adapter to the decTOP and connect it to your network to allow automatic configuration of the network interface.
- Insert the USB drive into the decTOP and power it up. The decTOP should automatically boot from the USB drive and start the Ubuntu installation.
- Answer only the first two questions concerning language selection and go to the next step, below.
- Press Alt-F2 (hold down the Alt key and press the F2 function key) to open a shell. Then press enter to start the shell.
- Create a /cdrom and a /dev/cdroms directory in the installation ramdisk
mkdir /cdrom /dev/cdroms - Go to the /dev/cdroms directory and build a symlink from /dev/sda1 (that is likely the device name of your USB boot partition) to /dev/cdroms/cdrom0.
cd /dev/cdroms
ln -s ../sda1/cdrom0 - While still in the shell, mount the USB drive to mimic an installation CD-ROM.
mount -t vfat /dev/cdroms/cdrom0 /cdrom - Return to the installation program with Alt-F1 and continue the installation.
From this point, the process should be identical to a routine CD-ROM installation. For a grand total of $140 and 8 watts of power consumption, I now have a near-silent Linux server running 24/7. You can telnet to it here and marvel at its blinding speed running a 250,000-sector Space Tyrant game. |
|
| | mail this link | permapage | score:9695 | -Ray, August 16, 2007 (Updated: July 7, 2009) |
|
Space Tyrant: A threaded game server project in C |
vote
|
|
[Update, June 25, 2005: A Space Tyrant home page has been created as a central index to the various ST articles, links, and files.]
[Update, March 21, 2007: A Space Tyrant has its own website! It's small but growing and will provide quick access to the latest code and developments in the ST universe.]
Space Tyrant: Today we kick off a new multithreaded, network socket programming project which we will call Space Tyrant. Our mission is to write an open source, multiplayer, networked, strategy game in the C programming language. The goal of this project is to make a solid code base which implements a simple space trading game upon which other games can then be built. The game will be a subset of The Last Resort (TLR) that currently runs at [offline]. This project will be a learning exercise for me as well as for any interested readers. The current state of the source code will be released with each article update.
The game design: While my TLR game consists of over 25,000 lines of C source code and supports a web interface as well as telnet and a graphical client, this code will be far smaller and simpler. It will initially only support telnet and will implement a far simpler game design.
Players will be able to telnet into the game, create an account, and play in a universe that contains ports, planets, as well as other players. Each player will be issued a starship, some cargo holds, and an amount of starship fuel. Additional fuel will be issued hourly and will accumulate in the starship. Fuel will be used to move the ship between sectors -- locations within the game universe -- and to dock with ports. Once a ship runs out of fuel it can't move at all until new fuel is issued.
Players will be able to buy and sell commodities (Iron, alcohol, and hardware) between the three different kinds of ports. Each port type will sell one of the three commodities and buy the other two. Prices will be based on supply and demand with rarely-used ports offering the better prices.
With the money players earn trading they will be able to buy more cargo holds to make their ships more efficient for trading. They will also be able to buy fighters -- small military drones -- that can be used to attack other ships or deployed to guard a sector and its contents. The fighters carried with a ship will guard it against attacks from other players.
Games will run for a predetermined length of time, then reset and start anew.
The programming model: Now, on to the software design. I've compared and considered various models for the server design. TLR is based on the forking model using inetd or xinetd to handle the listening and forking. While the forking model is inherently distributable to multiple processors, it introduces inefficiencies (forking multiple processes) and makes interprocess communications more difficult and slower.
Next, I considered a non-blocking, single process model. In this approach, one process handles everything in a single thread. It would use non-blocking IO (read and write functions that never wait for completion but, rather, return immediately if they aren't ready to read or write actual data). The thttpd web server is an example of a non-blocking, single process server. It's extremely fast and efficient. However, this model is quite complicated to code, and, I believe would make it more likely to introduce subtle timing bugs.
Next, I considered a pure multithreaded, single process model with a thread for each player. While appealing in many ways, this model would require the same kind of coordination between threads that the forking model requires between processes. Such interprocess communication would be simplified in that the various threads share memory, but the coordination issues otherwise remain the same.
Last, I considered another multithreaded model, this time with only IO threads for each user and a single thread that implements all game logic. While that one central thread might someday be a bottleneck that limits scalability on large SMP systems, it does distribute the IO on any additional processors that might be present, and requires minimal coordination. In short, this model combines the logic simplicity of the non-blocking single process model with the coding simplicity of the threaded model, while separating the IO from the main logic. There will also be two other simple threads in this model. There will be a thread that listens for new connections and spawns the IO threads for each new connection. There will also be a thread that writes the data to disk periodically.
This is the approach that I intend to take for this project. The code will be written for both Linux and Mac OS X.
More info: I have set up an email address for programmers following this series to provide recommendations, bug reports, and other feedback. Send email about this project to spacetyrant [at] librenix.com. |
|
| | mail this link | permapage | score:9597 | -Ray, March 18, 2005 (Updated: July 26, 2008) |
|
Install a Mail Server with Antivirus and Antispam in minutes |
vote
|
|
This article illustrates a situation where you need to set up your own mail server (be it your home mail server, or a small office one). It actually shows that, if using an integrated service mail server, anyone can do the job, all in a matter of minutes.
AXIGEN Mail Server, the solution chosen for this example, can send and receive e-mails securely via "mydomain.com" and is able to retrieve them in a WebMail interface - this means that it includes all mail services needed for a fully functional mail server (SMTP, IMAP, POP3, WebMail, WebAdmin).
To get an idea of the amount of time you can spare by installing such a solution, just think of all the different open source applications you would need to install instead (i.e. an MTA, Squirrelmail for Webmail, QmailAdmin for web configuration, Courier for IMAP and POP3 and many others.)
AXIGEN Mail Server can virtually integrate with any Antivirus/Antispam application and it comes with built-in connectors ClamAV Antivirus and SpamAssassin. The second part of this article shows you how to install these applications and configure these connectors for use with AXIGEN.
Thus, at the end of this process which can take up half an hour at most, you will not only have your mail server up and running, but also virus and spam protection for your incoming and outgoing mail traffic.
AXIGEN runs on several Linux distributions (Gentoo, Redhat/Fedora Core, Slackware, Debian, Ubuntu, Mandrake/Mandriva, SUSE), on BSD versions (FreeBSD, OpenBSD and NetBSD) and on Solaris but for the purpose of this article, let's suppose you are setting up your mail system on a Fedora Core 6 platform.In five easy steps, you will have your server installed, your primary domain running and access to the Web configuration interface (WebAdmin).
1. Download / unpack corresponding package
Download AXIGEN rpm package from the AXIGEN website (packages are available as 30 day evaluation versions). Save the corresponding package for Fedora Core 6 "axigen-2.0.4.i386.rpm.gcc4.tar.gz" on your local machine and unpack the file, by issuing in the same directory as the download file:
tar xzvf axigen-2.0.4.i386.rpm.gcc4.tar.gz
2. Install command
Then, in order to install the RPM package, issue (while logged in as root) the following command, from the same directory as the rpm file:
rpm -ivh axigen-2.0.4.gcc4-1.i386.rpm This will create the entire directory structure needed for AXIGEN to run. After the installation, no daemons or related application will be started.
3. Configuration options
AXIGEN provides several configuration options (configuration file, Command Line Interface), but the most intuitive and comprehensive one is WebAdmin, the Web configuration interface.
The corresponding WebAdmin service is enabled by default, as well as the other default services: IMAP, Logging, POP3, Processing and SMTP.
4. Initial configuration
The first configuration steps take place using the configuration wizard. You will set the administrator's password, select which services are started and what interfaces will be used. In this stage of the setup you also create the primary domain that your server will use.
The wizard can be run by issuing the following command in the console right after the installation of the package has finished:
/opt/axigen/bin/axigen-cfg-wizard NOTE: You have to make sure you do not start the mail server before the initial configuration.
5. Start AXIGEN
You can then start AXIGEN, using its initscript, by issuing this command:
/etc/init.d/axigen start Now that your server is running, you can connect the antivirus and anti-spam applications. By default, AXIGEN comes with connectors for the ClamAV Antivirus and SpamAssasin Antispam application. The setup process below describes how to make these two applications work with AXIGEN. However, note that AXIGEN implements a proprietary filter scripting language that allows you to implement connectors for any third party Antivirus and Antispam applications.
Connecting to ClamAV
A. Install ClamAV (daemon), on the same machine on which AXIGEN Mail Server is installed. Follow these steps in order to configure ClamAv for use with AXIGEN and start the clamd daemon.
1. Install clamav-server, using yum (Yellow Dog Updater, Modified):
yum install clamav-server 2. Copy the sample config file shipped with clamav-server:
cp /usr/share/doc/clamav-server-*/clamd.conf /etc/clamd.d/axigen.conf 3. Edit: /etc/clamd.d/axigen.conf
# comment out the Example line
# Example
# insert/modify the following lines:
LogFile /var/log/clamd.axigen
PidFile /var/run/clamd.axigen/clamd.pid
LocalSocket /var/run/clamd.axigen/clamd.sock
User axigen 4. Create a link to the clamd binary:
ln -s /usr/sbin/clamd /usr/sbin/clamd.axigen 5. Create the run directory, where the PID file and clamd socket will be stored, and change its permissions:
mkdir -p /var/run/clamd.axigen chown axigen:axigen /var/run/clamd.axigen 6. Create and setup the initscript:
cp /usr/share/doc/clamav-server-*/clamd.init /etc/init.d/clamd.axigen
chmod 755 /etc/init.d/clamd.axigen /sbin/chkconfig clamd.axigen on
7. Edit: /etc/init.d/clamd.axigen and modify the following lines, as specified below:
# description: The clamd server running for axigen CLAMD_SERVICE=axigen 8. Finally, start the clamd daemon:
/etc/init.d/clamd.axigen
B. Configure AXIGEN antivirus filter at server level using WebAdmin
In order to activate the ClamAV filter, go through the following steps:
In the "Server" context, click on the Add new filter button. This will open up and display the Active Filter list. It is empty right now, so we need to add the clamav filter to the list.
In the Priority field, enter a priority between 0 and 500 (a filter with priority 0 will be applied first and the one with 500, last).
Important - the domain-level filters have the priority limited to range 100-400 and the user-level filters are limited to the 200-300 range. A value of "10" should be fine, leaving you space to apply some other future filters before this one.
After setting the filter priority, select the socket value from in the Filter type dropdown list and the clamav value from the Filter Name list.
In the Apply on checklist, select the relay option, to apply the filter on outgoing mails. To make sure you scan both incoming and outgoing mails, you have to create the filter and select both values, local and relay.
In AXIGEN, it is possible to enable filters either at domain or user level, in the corresponding WebAdmin tabs. The filters activated at server level will be automatically applied for all domains and accounts. However, you have the possibility to add additional filters at domain or account level.
Connecting to SpamAssasin
The process for Connecting SpamAssassin is similar and even less time-consuming as no configurations are necessary after the product installation.
C. Install SpamAssassin using the yum application:
yum install spamassassin No further configurations are necessary.
D. Configure SpamAssassin at server level, using Webadmin
The connector for SpamAssassin is a socket filter for AXIGEN, so the configuration procedure is the same as for ClamAV. The difference would be that for SpamAssassin, a TCP socket is more likely to be used.
Also, when activating the SpamAssassin filter, you need to keep in mind the following:
- Enter a different priority value for the SpamAssasin filter (if you have chosen 10 for ClamAV, choose a higher value for SpamAssassin in order to apply this filter after ClamAV in the filtering chain)
- Select the corresponding filter name, spamassassin in the Filter name list
Access AXIGEN WebMail
At this step of the way, your mail server is ready to go, and you can also you can access the AXIGEN WebMail to send and receive test messages. Then, use the full email address and password to log on to AXIGEN WebMail, at the default address: http://127.0.0.1:8000, or use the address you specified in the initial configuration phase when you ran the setup wizard.
Now you're really done: you can securely send and receive messages from your home domain and easily make any further configurations, to accommodate your specific network requirements. As you have seen, installing all mail services from one single executable and an intuitive Web configuration interface make things a lot easier and a lot less time-consuming.
Authors:
Liviu Anghel, Chief Security Officer, Gecad Technologies
Ciprian Negrila, Technical Support Engineer, Gecad Technologies
read more... |
|
| | mail this link | permapage | score:9507 | -Kayla Vincent, February 6, 2007 |
|
Retrofit with JTip tooltips and GreyBox lightboxes |
vote
|
|
| Learn to retrofit a Web 1.0 shopping site with Ajax’s best practices. Discover how Ajax can improve user experience through principles of progressive enhancement. These principles eliminate pop-up windows and navigational dead ends using simple lightbox and tooltip techniques. |
|
| | permapage | score:9462 | -jmalasko, May 9, 2008 |
|
|
