Main Page
From GNU MyServer
MyServer is a powerful and easy to configure web server. Its multi-threaded architecture makes it extremely scalable and usable in large scale sites as well as in small networks, it has a lot of built-in features. Share your files in minutes!
GNU MyServer - News
Migration from SVN to GIT (03 Jun 2009)
I am pleased to announce that the MyServer source repository has been
migrated from subversion to GIT.
Anonymous checkout:
git clone git://git.savannah.gnu.org/myserver.git
If you are behind a silly firewall you can use the slower GIT via HTTP
by:
git clone http://git.sv.gnu.org/r/myserver.git
Developers can find more information here:
http://savannah.gnu.org/maintenance/UsingGit
It introduces a difference in the development model too: branches, that
may appear, are not hosted on the central repository.
Thank you SVN for the many years you helped us.
MyServer is an official GNU Project! (28 Jul 2008)
I am pleased to announce that MyServer has became an official GNU project!
GNU MyServer Development Blog
- Possibility to run the process with a different uid/gid even in the case MyServer has already setuid/setgid itself.
- No access to the MyServer file descriptor table.
- Much faster in the case fork is not implemented using pages copy-on-write
Plugins Manager and myserver-get Tool
Well, it’s time also for me to write something here:) the last months I worked on rewriting and refactoring the plugins management in MyServer, in order to simplify the inner management, the development and the outer (users-side) management of plugins.
To reach the first two goals, I removed all the different kind of plugins were defined before, in order to obtain a system simpler to manage. The plugins manager now perform versions checking and in a better way dependencies checking. If someone wants to write some plugin for myserver, and he find some trouble with the Plugins Manager or things there can be some improvement on it, I encourage him to write any idea on the mailing list 
To simplify the management of plugins for the end-users, I wrote a simply tool in python that will help the users to manage plugins. i called it myserver-get because of its similarities with the well known apt-get tool for packages management in debian-based GNU/Linux distributions.
It’s written in python, it works only with HTTP and FTP protocols, and implements the following commands:
- install: install a plugin or a list of plugins with all the dependencies.
- update: update the local plugins lists
- search: search for a plugin containing a word or a sentence in the description (use -v to have a more verbose response)
- source: download the sources of a plugin or a list of plugins.
- source-auto: download, compile and install a plugin or a list of plugins. this command doesn’t check for dependencies.
- remove: remove a plugin or a list of plugins.
a plugins repository should have the following features:
- a directory src with the source packages and a directory pub with the binary packages
- a file list.xml. You can find an example file that shows the simply syntax in the folder misc/myserver-get on the svn.
the source and binary packages should be created with the scons tool and the SConstruct file you can find in the plugins directory on the svn.
Myserver-get is not just a command-line tool, it’s also a library, in order to be easily included in a future GUI configuration and managing tool for MyServer.
MyServer fork server
Different reasons convinced me to write a “fork server” for MyServer. Having an external process to manage forks will lead to these advantages:
The fork server is initialized immediately after MyServer, it waits for connection on a TCP port and every time a process needs to be
spawned, two connections are opened to the fork server, they will be the stdin/stdout streams to the new process. These same connections are used by MyServer and the fork server to communicate before the new process is executed too. MyServer can be configured to change uid/gid after it is initialized but in this way it will not possible to set a different uid/gid for new processes because it has already lost root privileges.
A first test on the php process executed as a persistent FastCGI server shows how the file descriptor table is much smaller:
before (without the fork server):
php-cgi 0u TCP localhost:45275 (LISTEN)
php-cgi 1w 596 /dev/null
php-cgi 2u 3 /dev/pts/1
php-cgi 7u 26487 socket
php-cgi 8u 26488 socket
php-cgi 9u 596 /dev/null
php-cgi 10u 14631793 MyServerHTTP.err
php-cgi 11u TCP *:http-alt (LISTEN)
php-cgi 12u 14632158 MyServerHTTP.log
php-cgi 13u 14631624 MyServerHTTPS.err
php-cgi 14u TCP *:4443 (LISTEN)
php-cgi 15u 14632105 MyServerFTP.log
php-cgi 16u 14632107 MyServerFTP.err
php-cgi 17u TCP *:iprop (LISTEN)
php-cgi 18u 26610 can't identify protocol
php-cgi 19r 14811172 /tmp/myserver_2_3.tmp (deleted)
after (using the fork server):
php-cgi 0u TCP localhost:60391 (LISTEN)
php-cgi 1u TCP localhost:43856 (LISTEN)
php-cgi 2u 3 /dev/pts/1
php-cgi 3u TCP localhost:37548 (LISTEN)
Not that bad!
GNU TLS preferred instead of OpenSSL
Today I finally decided to work out this element of our task list. We are happy that now MyServer can be distributed under the GPLv3 terms license without any exception. Previously we were using OpenSSL for the HTTPS protocol, it was giving us some licensing troubles as we needed to add an exception to the original GPLv3 license.
The task was quite straightforward, GNU TLS is offering a nice abstraction layer on the OpenSSL APIs, only few functionalities were not present but it was easy to remove these incompabitilities.
For those interested to test it, the updated source code is available on the subversion repository.
MyServer agile development
After many discussions we finally decided to move our development model to something more dynamic, embracing some agile techniques like unit testing and test driven development.
The most important feature for this model is that code is frequently committed to the central subversion repository and project developers are allowed to commit patches without a previous review. In fact the review phase is postponed after the patch is committed and notified on a commits mailing list, where all developers can look at it and eventually show mistakes; in any case a commit must be done only after the source code is validated by the test suite. The main disadvantage is that the repository can contain not stable code but on the other hand, it is always updated and contains latest changes. Branches are not frequent but they are used in case a commit or a group of commits will change important features, e.g. switching to an event driven scheduler that changed the core classes of MyServer.
TDD is not used for normal classes development but it is required for bug fixing, where it is possible. In this way we will be sure the same bug will not appear again in the future. Old classes still are missing tests, not for all of all adding tests is a trivial task, in many cases there is need to refactor a lot of code before it is possible to write tests.
Some reports to help the development are automatically generated from the latest repository version source code and they are available in the Development section of the MyServer web site. A particular attention is given to the code complexity, methods must be as shorter as possible to make testing easier and especially to make the source code more readable.
We decided to have a release only when all the planned objectives are completed but until it is achieved some alpha releases can be done on fixed dates. After a release, new objectives are planned for a new cycle.