Language Selection

English French German Italian Portuguese Spanish

Linux Server Tournament, part 2

Filed under
Linux

Last time, we discussed which distros were going to be used in this setup.

Our nominees are BEL Server Basic (KDE), UServer 8.04 LTS, OpenSuse 11 and CentOS 5.

Situationally, we talked about what we felt were the 'keypoint' strengths' of each distro and what role we would fit them into the LAN as.

This is a small LAN, one of the purposes of using Linux as a server for our intents is to provide small/medium sized businesses an option that makes the most out of available resources. Which often means using equipment at hand or easily (low cost) gotten.

Each machine we will use will have no less than 512 MB of RAM and 120 GB hard drive. These are all p4/athlon equivalents and are very common in the field.

BEL Server Basic will be implemented as our webserver.

CentOS will take on mail server functions.

Ubuntu Server will handle authentication, including LDAP, DNS and related.

OpenSuse will handle file/print services.

All connections to the LAN will be wired, ethernet. There will be common switches used (Linksys, that sort).

There will be some non-free apps used, and HP printers as well, requiring HPLIP.

All the servers will be secured using what is currently offered on disk, as shipped, be it Bastille, SELinux, AppArmor, etc...

There has been a slight delay in acquiring the machines and space to put together this project, but it should be soon now things are coming back together.

We would like to hear from readers about their experiences implementing these distros in similar fashion, whether it be in the same server configuration or other.

More in Tux Machines

10 tips for onboarding open source contributors

Contributors are the lifeblood of many open source projects because they enable smaller projects to grow and improve without a lot of financial support and they bring fresh perspectives to the project. That is the case at Ushahidi, a non-profit organization that is building and using software to help raise the voices of underserved, marginalized communities. Our products enable local observers to submit reports about local humanitarian crises (such as political unrest and natural disasters) using their mobile phones or the internet, while simultaneously creating a temporal and geospatial archive of events. Ushahidi always strives for openness, but it's very hard to evaluate how open your organization works from the inside. Staff and longtime contributors know too much: they are cursed by knowledge and access to the people who know how things work. While a crisis brings out the good in people who want to help, getting involved with an open source project during a crisis is complex. The maintainers are usually going through a stressful time. New requests for features are coming every day. New bugs are being reported all the time. Read more

App Highlight: Open Source Disk Partitioning Tool GParted

GParted is undoubtedly one of the best partition managers for Linux out there. The user interface is very simple and gets the job done. In some cases, you end up using GParted to fix or format your USB drive as well. I had a USB disk which I couldn’t format in Ubuntu using the “Disks” app – this is where GParted came to the rescue. So, it is a quite useful tool with a lot of good features. Let me highlight them for you. Read more

Screencasts/Audiocasts: Zorin OS 15.1 Run Through, Linux Action News and Open Source Security Podcast

XFS - 2019 Development Retrospective

We frequently hear two complaints lodged against XFS -- memory reclamation runs very slowly because XFS inode reclamation sometimes has to flush dirty inodes to disk; and deletions are slow because we charge all costs of freeing all the file's resources to the process deleting files. Dave Chinner and I have been collaborating this year and last on making those problems go away. Dave has been working on replacing the current inode memory reclaim code with a simpler LRU list and reorganizing the dirty inode flushing code so that inodes aren't handed to memory reclaim until the metadata log has finished flushing the inodes to disk. This should eliminate the complaints that slow IO gets in the way of reclaiming memory in other parts of the system. Meanwhile, I have been working on the deletion side of the equation by adding new states to the inode lifecycle. When a file is deleted, we can tag it as needing to have its resources freed, and move on. A background thread can free all those resources in bulk. Even better, on systems with a lot of IOPs available, these bulk frees can be done on a per-AG basis with multiple threads. Read more Also: Oracle Talks Up Recent Features For XFS + Some File-System Improvements On The Horizon