Free server 3.12 software for linux

The SME Server server and gateway is free software (also referred to as open-source software) and is freely available for anyone to download.
This software is brought to you by the community and contribs.org. Many individuals and organizations (both commercial and non-profit) use the SME Server as their primary network server and gateway.
We would like to remind you that the SME Server software is licensed under the General Public License (GPL). This means that if you alter the software and distribute the altered version, you must make the source code for your altered version freely available.
The GPL is a large part of why free software has made such an impact on the commercial scene. By restricting anyone from making proprietary modifications, the GPL ensures that improvements find their way back to the original code base, thereby creating an explosive rate of technical advance.
The difference between traditional development and GPL development is the difference between a light bulb - where output is radiated in many directions - and a laser - where output is reflected back in a coherent way to produce a greater, more focused result.
Its main design focus is simple, centralized configuration, along with security and ease of installation.
Enhancements:
- This release is based on CentOS 4.5 and all packages have been updated to the latest releases. This release contains many new features, all released updates for SME Server 7.1 and fixes for many reported problems. Upgrades will be available by CD, the Software Installer and command line. All users should upgrade to this release.

Linbox Directory Server (LDS), along with the Linbox Management Console (LMC), is a powerful system that allows developers, system administrators, and other software vendors to manage users, groups, and their associated policies in an LDAP server.
Linbox Directory Server is highly ergonomic interface design makes it very easy to use, and delegation of administration enables medium size organization to adopt LDS.
Enhancements:
- New features and improvements include DNS/DHCP management and a Norwegian translation.
- The new DNS/DHCP module allows you to manage DNS zones and DHCP subnets for a typical LAN environment.

Mail::Bulkmail is a platform independent mailing list module.

SYNOPSIS

use Mail::Bulkmail /path/to/conf.file

my $bulk = Mail::Bulkmail->new(
"LIST" => "~/my.list.txt",
"From" => "Jim Thomason" ,
"Subject" => "This is a test message",
"Message" => "Here is my test message"
) || die Mail::Bulkmail->error();

$bulk->bulkmail() || die $bulk->error;

Dont forget to set up your conf file!

Mail::Bulkmail gives a fairly complete set of tools for managing mass-mailing lists. I initially wrote it because the tools I was using at the time were just too damn slow for mailing out to thousands of recipients. I keep working on it because its reasonably popular and I enjoy it.

In a nutshell, it allows you to rapidly transmit a message to a mailing list by zipping out the information to them via an SMTP relay (your own, of course). Subclasses provide the ability to use mail merges, dynamic messages, and anything else you can think of.

Mail::Bulkmail 3.00 is a major major major upgrade to the previous version (2.05), which was a major upgrade to the previous version (1.11). My software philosophy is that most code should be scrapped and re-written every 6-8 months or so. 2.05 was released in October of 2000, and Im writing these docs for 3.00 in January of 2003. So Im at least 3 major re-writes behind. (philosophy is referenced in the FAQ, below)

But thats okay, because were getting it done now.

3.00 is about as backwards compatible to 2.00 as 2.00 is to 1.00. That is to say, sorta. Ive tried to make a note of things where they changed, but Im sure I missed things. Some things can no longer be done, lots are done differently, some are the same. You will need to change your code to update from 1.x or 2.x to 3.00, though. Thats a given.

So whats new for 3.00? Lots of stuff.

Immediate changes are:

* code compartmentalization
* multi-server support
* conf file

The immediate change is that the code is now compartmentalized. Mail::Bulkmail now just handles ordinary, non-dynamic mailings. See Mail::Bulkmail::Dynamic for the merging and dynamic text abilities from the prior versions.

Server connections are no longer handled directly in Mail::Bulkmail (Smtp attribute, Port attribute, etc.), there is now a separate Mail::Bulkmail::Server object to handle all of that.

And everything subclasses off of Mail::Bulkmail::Object, where I have my super-methods to define my objects, some helper stuff, and so on.
Its just a lot easier for me to maintain, think about it, etc. if its all separated. Its also easier for you, the user, if you want to make changes to things. Just subclass it, tweak it, and use it. Very straightforward to modify and extend now. 2.x and below *could* do it, but it wasnt really that easy (unless you were making very trivial changes). This should rectify that.

Another major change is the addition of multi-server support. See the docs in Mail::Bulkmail::Server for more information. You can still specify one SMTP relay if thats all youve got, but if you have multiple servers, Mail::Bulkmail can now load balance between them to help take the stress off. No matter what, the biggest bottleneck to all of this is network performance (both to the SMTP relay and then from the relay to the rest of the world), so i wanted to try and help alleviate that by using multiple servers. I know that some people were doing that on there own with small changes, but this allows you to do it all invisibly.
And finally, finally, finally there is a conf file. Documentation on the format is in Mail::Bulkmail::Object. Its pretty easy to use. This is the conf file format that I designed for my own use (along with most of the rest of Mail::Bulkmail::Object). The software also has the ability to read multiple conf files, if so desired. So no more worrying about asking your sysadmin to tweak the values in your module somewhere up in /usr/lib/whatever

Just have him create the conf file you want, or pass in your own as desired.
conf_files are specified and further documented in Mail::Bulkmail::Object, in an internal array called @conf_files, right at the top of the module. To specify a universal conf file, put it in that array (or have your sysadmin do so). Alternatively, you can also add a conf_file via the conf_files accessor.

Mail::Bulkmail->conf_files(/path/to/conf_file, /path/to/other/conf_file); #, etc.

But the recommended way is to specify your conf file upon module import.

use Mail::Bulkmail 3.00 "/path/to/conf/file";

In addition, there is the usual plethora of bug fixes, tweaks, clean-ups, and so on.

And yes, the horrid long-standing bug in the Tz method is fixed! No, honest.
Im also trying a new documentation technique. The pod for a given method is now in the module by that method, as opposed to everything being bunched up at the bottom. Personally, I prefer everything being bunched up there for clarities sake. But from a maintenance point of view, spreading it all out makes my life much easier.

TFTP Server is a multi-threaded TFTP server, which means any number of clients can connect simultaneously.
TFTP Server supports tsize, blksize, and interval options, supports PXE boot, and can be run standalone or as a daemon.
TESTING
This server runs in Debug Mode (with flag -v) or as Service (without any flag). Please expand the .gz file to an directory, using shell, goto that directory, edit tftpserver.ini file (just specify home dir) and give following command as root:-
tftpserver#./tftpserver -v
You will see following results:-
Ready...
Now open one more shell and give following commands:-
$tftp
tftp>connect localhost
tftp>get [some file name in home dir]
Received 13112 bytes in 0.0 seconds
and on server you may see
client 127.0.0.1:xxxxx file ...... # blocks served
INSTALLATION
This program runs in two modes:-
a) Debug Mode (using -v argument)
b) Daemon (using no argument)
This program should be setup to start automatically modifying boot scripts /etc/rc.d/rc.local file or /etc/inittab file. Never include -v (verbatim flag) while running as Daemon from these scripts.
CONFIGURATION
You need home directory to be set in tftpserver.ini file, you can comment other parameters like blksize and interval.
UNINSTALLATION
Just remove the program directory. You should also remove entries from initialize scripts of
your machine.
Enhancements:
- This release uses Thread Pool, which improves performance.
- Log file and ini file locations can now be overridden in the Unix version.

HA-Proxy is a TCP/HTTP reverse proxy which is particularly suited for high
availability environments. Indeed, it can :
- route HTTP requests depending on statically assigned cookies ;
- spread the load among several servers while assuring server persistence through the use of HTTP cookies ;
- switch to backup servers in the event a main one fails ;
- accept connections to special ports dedicated to service monitoring ;
- stop accepting connections without breaking existing ones ;
- add/modify/delete HTTP headers both ways ;
- block requests matching a particular pattern ;
It needs very little resource. HAproxy it is event-driven architecture allows it to easily
handle thousands of simultaneous connections on hundreds of instances without risking the systems stability.
Start parameters
There are only a few command line options :
-f < configuration file >
-n < high limit for the total number of simultaneous connections >
-N < high limit for the per-proxy number of simultaneous connections >
-d starts in foregreound with debugging mode enabled
-D starts in daemon mode
-q disable messages on output
-V displays messages on output even when -q or quiet are specified.
-c only checks config file and exits with code 0 if no error was found, or exits with code 1 if a syntax error was found.
-p < pidfile > asks the process to write down each of its childrens pids to this file in daemon mode.
-s shows statistics (only if compiled in)
-l shows even more statistics (implies -s)
The maximal number of connections per proxy is used as the default parameter for each instance for which the maxconn paramter is not set in the listen section.
The maximal number of total connections limits the number of connections used by the whole process if the maxconn parameter is not set in the global section.
The debugging mode has the same effect as the debug option in the global section. When the proxy runs in this mode, it dumps every connections, disconnections, timestamps, and HTTP headers to stdout. This should NEVER be used in an init script since it will prevent the system from starting up.
Statistics are only available if compiled in with the STATTIME option. Its only used during code optimization phases.
Enhancements:
- Content switching is now fully operational using ACLs.
- ACLs can look for matches in path and headers in addition to previously supported criteria.
- Integer comparison is now supported for header values. 15 pre-defined ACLs are provided.
- Error pages can be customized using external files.
- Several bugs have been fixed.
- This version will be maintained as a stable one during further development.