Faztek's unnofficial Blog

My first blog is dedicated to Internet hosting software.

quarta-feira, dezembro 19, 2007

Sourceforge is great, and complex

Sourceforge is a great, vast site.
For the end-user, it's appealing, and easy to work; for the packager, programmer, site maintainer, is most complex. In my opinion the worst aspect of maintainability is the way the "File Release" is organized. Uploads take around 15 mins, excluding the time for the files to be uploaded...

Here's the snapshot of one of the steps to make the file release:

[henrique@fuji t]$ ftp upload.sourceforge.net
Connected to upload.sourceforge.net (66.35.250.221).
220-********************************************************************
220- SourceForge.net FTP server - San Jose (osdn.dl.sourceforge.net)
220- Mirrors, try 'rsync osdn.dl.sourceforge.net::'
220-
220- Got a fat pipe and something to prove? Host a SourceForge download
220- server! Email ftpadmin@sourceforge.net for opportunities.
220-
220- On This Site:
220- /incoming SourceForge.net Project File Upload
220- *********************************************************************
220-
220
Name (upload.sourceforge.net:henrique): anonymous
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> bin
200 Switching to Binary mode.
ftp> cd /incoming
250 Directory successfully changed.
ftp>
[followed by regular ftp commands]

You can surely use another ftp client, but this is just one of the steps!
Then you have to go along multiple pages and buttons, wait for the pages to update, writing / uploading the release notes.

The great advantage is the impressive uptime and bandwidth of Sourceforge servers.
As of today, there were 164,955 projects, and 1,751,725 users. It's really impressive.

On my own, I have two projects: they are libUnicode-Plus, from which the Wiki and packaging has most of the work, and mp3query - I have paused this project.

sábado, dezembro 01, 2007

Rotating logs, a script - especially useful for Freesco boxes

Logs in a Freesco-box are limited by default: /var/log (or actually var) is mounted on RAM.
Since my Freesco-box is small, like most boxes around with Freesco, and I have Exim running, I felt the need for rotating exim logs. logrotate is an expensive solution for these boxes.
Limited RAM space looks like this:
[Linux] df /
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/ram0 2901 2005 896 69% /

Having logs on RAM improves speed, but if space runs out, Exim just dies.
Fortunately since v0.3.2 there is an almost (*) automatic detection of lost network. In this case network is shut down and restarted, along with a nice rc_user stop and start. This is handled in Freesco rc scripts as newip. I also stop and start Exim in such cases; it is not necessary, but since network is down anyway, it gives me some advantage to use this restart to spin logs around.
At my rc_user I call the script fbox_save_logs.sh in-between rc_exim stop and rc_exim start:
fbox_save_logs.sh is, so to speak, a poor parent of logrotate, but does its job nicely in this small box.

Refer to:

(*)
It is written "almost" detects, because due to a Kernel bug, network hangs sporadically.
Try this script, if suits for your Freesco-box: