Free appliances software for linux

Virtual Appliances are nano-sized virtual machines with Web user interfaces for deploying instant infrastructure and applications.
The are Gentoo Linux based and optimized for use in VMware.
Summary Instructions for using the Base Virtual Appliance
Download the Virtual Appliance.
If you do not have VMware Player, Workstations, Server, GSX, or ESX, Download VMware Virtual Player or VMware Virtual Server and install it.
Unpack the Virtual Appliance zip or tar.bz2 file.
Use your VMWare product to open and run the VirtualAppliancesBase.vmx file
Observe your VMWare console. The Virtual Appliance IP address will be printed there.
Using your Web Browser, open the Virtual Appliance Management console at https://your_ipaddress:8000/
The Mangement console listens on port 8000 and uses https.
Login to the admin console. The factory username:password is admin:admin.
Change the admin password to something secret through Configuration|Authentication
Enter shared storage information in Configuration|Storage
Your shared storage files will now be available via the webserver on the Virtual Appliance at http://your_ipaddress
Enhancements:
- This is a new Virtual Appliance featuring an instant PostgreSQL server and phpPgAdmin.
- It is a fully self contained Virtual Appliance, only 14MB to download, and ready to use with no configuration.

Net::Appliance::Phrasebook is a Perl module for network appliance command-line phrasebook.

SYNOPSIS

use Net::Appliance::Phrasebook;

my $pb = Net::Appliance::Phrasebook->new(
platform => IOS,
source => /a/file/somewhere.yml, # optional
);

print $pb->fetch(a_command_alias), "n";

If you use Perl to manage interactive sessions with with the command-line interfaces of networked appliances, then you might find this module useful.

Net::Appliance::Phrasebook is a simple module that contains a number of dictionaries for the command-line interfaces of some popular network appliances.

It also supports the use of custom phrasebooks, and of hiearchies of dictionaries within phrasebooks.

Argante provides a secure, distributed, and fast VS machine.

Argante is a fully operational, virtual environment for effective, secure, and accurate development of network appliances and other solutions (distributed routers, heterogenic, and self-adapting clusters).

Argante is a fully virtual environment for running applications on Unix
systems. This makes many people think about Java and its sandbox for example, although the technical reasons Argante is based on were totally different.

For one thing, Argante is a complete operating system. It has its own
implementation of processes, inter-process communication, filesystem,
access control... All built on the top of basic real OS low-level
implementation, but with own control mechanisms, own semantics and so on.
Why all this? I will try to explain:

The standard architecture of operating systems and hardware (e.g processors) falls flat when it comes to security and stability of the software.
To be short: it lacks low lewel support for general access control, error
handling (primitive techniques existing in, say, the 80386 series are not
enough), and the architecture of stack or data segment usage is based on
some mistaken assumptions.

rPath Linux is a Linux distribution built with the new Conary distributed software management system.

rPath Linux provides the foundation for creating software appliances that is:

Easily tailored to any application requirements
Built using Conary packaging technology, rPath Linux provides a more fine-grained breakdown of system components than in typical Linux environments. This allows application developers using rBuilder to pick just the pieces they need to support their application.

Engineered to the highest levels of quality
The rPath engineering team has a long history of delivering high quality Linux technology to demanding enterprise customers and software vendors. They have taken the lessons learned from these customers and partners and built rPath Linux to meet the demands of today’s corporate IT environments.

Compatible with many popular commercial Linux distributions
If you already offer your application on Linux, it will likely run unchanged on rPath Linux, so there is minimal effort required to offer your application as a software appliance.

KLone is a fully-featured, multiplatform, web application development framework, targeted especially for embedded systems and appliances.
It is a self-contained solution which includes a web server and an SDK for creating WWW sites with both static and dynamic content. When using KLone, theres absolutely no need for any additional component: neither the HTTP/S server (e.g. Apache, Netscape, Roxen), nor the typical active pages engine (PHP, Perl, ASP, Python).
KLone project does everything, and does it fast and small.
KLone blends the HTTP/S server application together with its content and configuration into a single executable file. The site developer writes his/her dynamic pages in C/C++ (in usual scripting style: < % /* code */ % >) and uses KLone to transform them into embeddable, compressed native code with the native C/C++ compiler. The result is then linked to the HTTP/S server skeleton to obtain one single, ROM-able, binary file. This means that he/she can get:
- easy, complete and unfiltered interaction with the host operating system
- dynamic pages in native compiled code, which in turn implies
- fast execution and
- small overall application footprint [1]
- all of this without giving up the common functionality of web application frameworks such as sessions, parsing of form variables, cookies, etc.
Enhancements:
- A newline is always added after < %! % > C translated code.
- Posted data can have content-length equal to zero.
- Unmatched single or double quotes in kl1 blocks no longer cause compilation errors.
- SA_RESTART is used for all signal handlers to avoid EINTR when calling syscalls from within .kl1 pages.
- More console messages are printed on startup errors.

Sanos is a minimalistic 32-bit x86 OS kernel for Java based server appliances running on standard PC hardware.
This enables you to run java server applications without the need to install a traditional host operating system like Windows or Linux. Only a standard Java HotSpot VM and the sanos kernel are needed.
The kernel was developed as part of an experiment on investigating the feasibility of running java server applications without a traditional operating system only using a simple kernel.
The kernel implements basic operating system services like booting, memory management, thread scheduling, local and remote file systems, TCP/IP networking and DLL loading and linking.
A win32 layer allows the Windows version of the standard HotSpot JVM to run under sanos, essentially providing a JavaOS platform for server applications. This enables you to run java based server applications, like tomcat and jboss, under sanos.
Alternatively, you can use sanos as a small kernel for embedded server applications written in C. Sanos has a fairly standard POSIX based API and an ANSI Standard C library. In this case you dont need the JVM and the win32 wrappers.
Sanos is open source under a BSD style license. Please see the COPYING file for details.
Click on the topics below for further information, or send me an e-mail if you have any questions, comments or problems regarding sanos. Please include the word sanos in the mail to prevent it from being intercepted by my spam filter.
Sanos can be downloaded as either binary or source. All the files in the binary version can be built from the source version, so you do not need the binary version, if you are building sanos from source.
The binary version contains the compiled version of sanos, with files and utilities for making a boot disk.
The source version contains all the source code and build files for building sanos from source. You will need a Microsoft Visual C compiler to build sanos from source.
Enhancements:
- GetLogicalDrives() in kernel32 implemented.
- A bug in cmd_ipconfig() in sh.c prevented proper display of network configuration if no DNS servers was configured. This problem has been fixed. (FGA)
- New -a option added to mkdfs to support file lists with alternative files names. This simplifies configurations with both debug and release builds.
- The Visual Studio wizard can now generate a floppy disk boot image configured for the application.
- Shell prompt can be configured by setting the prompt property in the [shell] section of the os.ini file.
- If command line arguments are given to the shell it now executes the built-in command and exits the shell.
- The floppy motor timeout routine now acquires the floppy mutex before turning off the motor in order to prevent race conditions.
- Advanced Power Management (APM) support implemented. The computer can now be powered off after os shutdown. The mode parameter for exitos() can be used to specify the shutdown mode (halt, reboot, poweroff, debug). A shutdown command has been added to the shell. The power status can be retrieved using /proc/apm.
- Added /proc/cpu for CPU information.
- The raise() function now returns an error if the signal number is invalid.
- Breakpoint traps are now sent to the user mode signal handler. This allows breakpoints to be handled by user mode code.
- Signals now exits the currently executing job with the signal number as exit code. However, if the debug flag in the PEB is set the debugger is entered if an unhandled signal is encountered. The debug flag can be set using the debug command in the shell. The debug flag can be configured using the debug property in the [os] section of os.ini. The default value of the debug flag is 0, unless the system is build in debug configuration.
- readv() and writev() implemented in vfs.
- The kernel log is now implemented by the device driver /dev/klog. The kernel log now support ioctl for waiting for new log entries in the kernel log. The kprintf has been extended to support different log levels.
- The syslog interface has been redesigned in to comply with POSIX. The syslog now supports logging to a syslog server by setting the loghost property in the [os] section of os.ini.
- New klog daemon to read entries from the kernel log (/dev/klog) and add them to the system log.
- The sockaddr and sockaddr_in structures has been change to conform to winsock definitions.
- The sleep() function has been renamed to msleep(). A new POSIX conformant sleep function has been added to unistd.h.
- Added sys/time.h header file. Also added tzp parameter to gettimeofday() for POSIX compliance.
- New simple text editor utility (edit.exe) added.
- The syserror() function has been moved from libc.lib to the os.dll as an exported os api call.
- readline() now uses stdin and stdout for input and output.
- Bug in iomux fixed. Now a monitored event signals the iomux and not the associated object.
- Implemented popen() and pclose(). Also added a P_SUSPEND parameter to spawn() to allow new jobs to be started suspended.
- The kernel version information is now kept in a version resource in krnl.dll. The version information is retrieved using the new module version information functions in verinfo.c.
- The build type can now be controlled by compile time switches. The kernel version can be displayed in the Windows Explorer by viewing Properties for krnl.dll and selecting the Version tab.
- User management added to kernel. Each thread is now assigned to a user and a group. A thread has both a real and an effective user and group owner. The {get|set}[e]{uid|gid}() functions can be used to change the effective and real user and group for a thread. When a new thread is created the effective user and group are inherited from the creator thread.
- Added functions to query /etc/passwd and /etc/group files.
- New whoami, id, chmod, and chown commands added to shell. The format of the output from ls has been changed to display the file permission info.
- New file system version for DFS. The new version supports user and group owner for files and directories as well as permission bits. The new DFS version also supports files larger than 2GB. The fchown() and chown() functions has been added to vfs.
- DES-based crypt() implementation added.
- The spawn() function now computes the pgm parameter from the cmdline parameter if the pgm parameter is NULL. The initpgm and initargs properties in the [os] section of /etc/os.ini has been replaced with a single property named init. The default for init has been changed to /bin/sh.
- The behavour of the initial application has been changed. Previously the os shut down after the initial application exited. Now the initial application is executed again if it exits.
- Telnet daemon moved from the shell to separate server (telnetd.exe). The new telnet daemon has a more robust handling of the telnet protocol. The telnet daemon invokes the new login utlity in order to log on user.
- FTP daemon implemented.

Linux NFS Utilities are NFS utilities for Linux NFS clients and servers.
Main features:
- NFS Versions 2, 3, and 4 are supported on 2.6 and later kernels.
- NFS over UDP and TCP on IPv4 are supported on the latest 2.4 and 2.6 kernels.
- Linux NFS clients and servers have been tested against many non-Linux implementations.
- Since version 1.0.1 of the NFS utilities tarball has changed the server export default to "sync", then, if no behavior is specified in the export list (thus assuming the default behavior), a warning will be generated at export time.
- If you plan to deploy NFS extensively, consider subscribing to one of these mailing lists: NFS Mailing List, or the AutoFS Mailing List. Before reporting problems, you should search for similar issues in the searchable mail archive. Another searchable archive for NFS, supported by Google, is here. The searchable mail archive for AutoFS is here.
- A useful set of generic NFS references includes the following:
- - "NFS Illustrated," by Brent Callaghan; Addison-Wesley, 2000.
- - "Managing NFS and NIS, 2nd edition," by Hal Stern, Mike Eisler, Ricardo Labiaga; OReilly, 2001.
- - "Linux NFS and Automounter Administration," by Erez Zadok; Sybex, 2001.
- - "Using the Linux NFS Client with Network Appliance Filers," by Charles Lever; Netapp TR-3183, 2004.
- - "Mike Eislers NFS blog."
- - "Eric Kustarzs blog."
- - "NFS version 4 home page."
- - Finally, the "linux.org online library" has many references.
Quick setup client guide
1. Acquire and install a recent distribution of Linux.
2. Set up your /etc/exports file (man exports for details).
3. Consult your distributions documentation to determine which /etc/init.d start-up script is used to start your server. Start NFS services by invoking this script as root, using the "start" parameter. Consider adding this script to the list of scripts that are automatically run at system start-up. (Red Hat uses the chkconfig command for this purpose).
4. Read the NFS How-To for advice on tuning and securing your server.
Quick Client Setup Guide
1. Acquire and install a recent distribution of Linux. To enable NLM lock recovery, ensure your clients host name, as returned by uname -n, matches the host name returned by DNS.
2. The NLM protocol is handled by an in-kernel service in modern kernels, but the user-level rpc.statd program must be running to enable NLM lock recovery. Consult your distributions documentation to determine which /etc/init.d start-up script is used to start it. Start the NSM daemon by invoking this script as root, using the "start" parameter. Consider adding this script to the list of scripts that are automatically run at system start-up. (Red Hat uses the chkconfig command for this purpose).
3. Create the directories on your client where you will mount the NFS shares.
4. Add entries in /etc/fstab corresponding to your mount points (man nfs for details).
5. Use mount -a -t nfs to mount the NFS shares.
6. During system boot-up, most distributions automatically mount NFS shares that are listed in /etc/fstab. If yours doesnt, check your distributions documentation for instructions on how to configure your client to do this.
Enhancements:
- The "mount.nfs" command was added, since the nfs mount functionality is being migrated from util-linux to nfs-utils.
- Substantial changes to were made statd. Various pieces of old code were removed.
- Lots of bugfixes and improvements were made.

cec (Coraid Ethernet Console) client, can connect to any CEC server over raw ethernet. Coraid appliances are examples of CEC servers.
Cec is also the name of the client used to connect to cec servers. Cec will run on linux, and bsd flavors supporting bpf. By default the makefile is linux ready -- just run make. To compile a bsd binary, run
make PLATFORM=bsd
or edit the makefile accordingly.
Documentation
See the cec.8 manpage. To read the manpage before installation, some
versions of man accept a "-l" option:
man -l cec.8
... while on other systems groff may be used.
groff -Tascii -mandoc cec.8 | less
Enhancements:
- Solaris support was added.
- An "install" target was added to the makefile.
- Minor bugs were fixed.