Slashdot Mirror

Webmin will load all the right packages and set up Apache, mail, DNS etc. for you on a variety of Linux distributions.You can use it like a control panel afterwards or just ignore it and use the usual text config files and the command line from then on if you want. It's free and quick to run. I find it saves a lot of time (and mistakes). I made a tutorial if that's any use.

I agree Virtualmin GPL or Virtualmin Pro.
Fantastic community support as well as professional support from the Developers.
I started on Webmin years ago. It was so helpful I finally bought Virtualmin Pro 50 server license.

I use the latest Ubuntu 11.04 as my daily system however on a server I use Centos because of it's Long Term Support (LTS).

Ubuntu 10.04 (LTS) is a rock solid server as well.

I just prefer Centos and Scientific Linux because they are based on Redhat Enterprise binaries and I grew up on Redhat so it is just easier for me.

INSTALL a Linux DESKTOP install.
Don't do the server install because the Virtualmin install.sh script downloads, installs and configures everything using the Virtualmin repositories.

You can do it with a minimal install that gives you only a shell to start but I like to start with a minimal Desktop install for convenience.

Go to http://www.webmin.com/vinstall.html [webmin.com] and download the install.sh script.
bring up the shell terminal and execute the 2 commands they give on the above page
I just tested it yesterday on the new Centos6 and it did the setup flawlessly.

After it completes the install you'll be able to examine how they setup everything in the server.

You may want to test it on Scientific Linux as it is based on Redhat Enterprise.
http://www.scientificlinux.org/ [scientificlinux.org]

I use ubuntu 11.04 on my desktop but I use Centos5.3 on my servers and am now in the process of upgrading to Scientific Linux6 which in essence is Centos6 or Redhat Enterprise6

There is a debate about Centos kind of dragging their feet and many are switching to Scientific Linux since it is looking to be aggressively maintained.

Read this post.
http://www.virtualmin.com/node/17463#comment-80722 [virtualmin.com]
For some reason the post link in the drupal forums would not link to the one I wanted however if you search the above link thread for Posted: Wed, 2011-05-04 14:51
and read from there, it may cause you to try scientific Linux.

You have to be root for the script to install the system. Centos already has the Root user enabled.

In Ubuntu, you'll need to temporarily enable the root user, then disable it after Virtualmin installs.

I suggest Centos6 for your first test because I know the install.sh script worked OK on it. I'll assume it will work in Scientific Linux since the binaries are the same as Centos or Redhat Enterprise.

I think, Joe at Virtualmin mentioned they are going to switch from Centos to Scientific Linux for their servers.

http://www.virtualmin.com/os-support [virtualmin.com]

Virtualmin GPL Supported Systems
The automated installation script supports the following operating systems:

CentOS 5 and 6 on i386 and x86_64
RHEL 5 and 6 on i386 and x86_64
Scientific Linux 6 on i386 and x86_64
Debian 5.0 and 6.0 on i386 and amd64
Ubuntu 8.04 LTS and 10.04 LTS on i386 and amd64

All Virtualmin GPL supported systems are considered "Grade A" and provide an excellent platform for virtual hosting

* * * *

Here is a little background to try and convince you to give Virtualmin a try.

You're in for a wild ride being new to LAMP servers. Running a Linux server is an addictive experience. A blessing and a curse ;-)

In 2002 on Redhat 7.3. I hired a friend, Lee Bertagnolli, to help me get my first server going. He setup the server manually.

I couldn't follow all he did at the time. I was an ultra Linux noob

I agree with Virtualmin GPL or Virtualmin Pro.
Fantastic community support as well as professional support from the Developers.
I started on Webmin years ago. It was so helpful I finally bought Virtualmin Pro 50 server license.

I use the latest Ubuntu 11.04 as my daily system however on a server I use Centos because of it's Long Term Support (LTS).

Ubuntu 10.04 (LTS) is a rock solid server as well.

I just prefer Centos and Scientific Linux because they are based on Redhat Enterprise binaries and I grew up on Redhat so it is just easier for me.

INSTALL a Linux DESKTOP install.
Don't do the server install because the Virtualmin install.sh script downloads, installs and configures everything using the Virtualmin repositories.

You can do it with a minimal install that gives you only a shell to start but I like to start with a minimal Desktop install for convenience.

Go to http://www.webmin.com/vinstall.html and download the install.sh script.
bring up the shell terminal and execute the 2 commands they give on the above page
I just tested it yesterday on the new Centos6 and it did the setup flawlessly.

After it completes the install you'll be able to examine how they setup everything in the server.

You may want to test it on Scientific Linux as it is based on Redhat Enterprise.
http://www.scientificlinux.org/

I use ubuntu 11.04 on my desktop but I use Centos5.3 on my servers and am now in the process of upgrading to Scientific Linux6 which in essence is Centos6 or Redhat Enterprise6

There is a debate about Centos kind of dragging their feet and many are switching to Scientific Linux since it is looking to be aggressively maintained.

Read this post.
http://www.virtualmin.com/node/17463#comment-80722
For some reason the post link in the drupal forums would not link to the one I wanted however if you search the above link thread for Posted: Wed, 2011-05-04 14:51
and read from there, it may cause you to try scientific Linux.

You have to be root for the script to install the system. Centos already has the Root user enabled.

In Ubuntu, you'll need to temporarily enable the root user, then disable it after Virtualmin installs.

I suggest Centos6 for your first test because I know the install.sh script worked OK on it. I'll assume it will work in Scientific Linux since the binaries are the same as Centos or Redhat Enterprise.

I think, Joe at Virtualmin mentioned they are going to switch from Centos to Scientific Linux for their servers.

http://www.virtualmin.com/os-support

Virtualmin GPL Supported Systems
The automated installation script supports the following operating systems:

CentOS 5 and 6 on i386 and x86_64
RHEL 5 and 6 on i386 and x86_64
Scientific Linux 6 on i386 and x86_64
Debian 5.0 and 6.0 on i386 and amd64
Ubuntu 8.04 LTS and 10.04 LTS on i386 and amd64

All Virtualmin GPL supported systems are considered "Grade A" and provide an excellent platform for virtual hosting

* * * *

Here is a little background to try and convince you to give Virtualmin a try.

You're in for a wild ride being new to LAMP servers. Running a Linux server is an addictive experience. A blessing and a curse ;-)

In 2002 on Redhat 7.3. I hired a friend, Lee Bertagnolli, to help me get my first server going. He setup the server manually.

I couldn't follow all he did at the time. I was an ultra Linux noob at the time.

I made a Ghost backup of the drive in case I messed it up so I could restore and be up and running again.

What really sped up my learning was the discovery of Webmin.

This is a link to the Virtualmin Installer and it mentions CentOS is supported so that is definitely another possibility. Personally I went with Ubuntu due to how many people are using Ubuntu and the fact that it supported this installer, but CentOS is definitely another good choice.

TL;DR: commandline-only interface on the server is fine, since you won't be administering the server locally in most cases.
To implement: "sudo apt-get install webmin sshd knockd", then read the documentation and edit/create your configuration files.

Webmin is a useful tool for "avoiding the command line"; it gives you a browser-based interface to many common server systems and tools.

Between webmin and SAMBA, you can avoid the CLI for many common tasks, if that truly is your goal.

On the other hand, if you're serious about administering your server, you'll just bite the bullet and learn the handful of commands you'll need on the CLI to do the things you need to do, and read the man pages for ssh ("Secure SHell", a remotely accessible command-line interface using cryptographic security measures).

Implement port-knocking (Google "knockd"), use a non-standard SSH port, and implement certificate-based security to simplify your security concerns and keep the bots from being able to crack your sshd.

None of my servers have anything attached except power and network, unless/until there is a reason to interact directly with them - remote administration is the way to go.

If you want to have a general purpose full-featured Linux server distro that will be easy to set up and maintain, and be flexible enough to adapt to any purpose, choose either Ubuntu or CentOS (the Redhat clone).
They are easy to work with, and both can do everything.
(I'm guessing you're going to be physically sat at the computer while you're working on it, or working over VNC or some such, and that therefore you'll want a GUI - in this case use the usual Ubuntu desktop installer (rather than the -server edition which contains no GUI stuff).

Otherwise, if you want a quick and easy route to LAMP web serving, then the above suggestions of XAMPP, Zend, and also possibly Bitnami are the obvious choices. (They don't necessarily involve Linux though.)

Personally, I would recommend Ubuntu. It is a cinch to install and set up, great active community support, and you're not limited in what you can do.

Here's a little demo of what setting up LAMP on Ubuntu would look like. You can get where you want to be pretty quickly:

- download and install Ubuntu to the server (installation could be 10 minutes)
- open a terminal and type:
    # sudo apt-get install apache2 mysql-server phpbb3
(this will take probably 2-3 minutes to complete)

You are now 90% set up with your LAMP server. Current versions of Apache, Mysql, PHP, phpbb3 and all their specific dependencies are now installed AND running.
Time to configure the services!

If you want to stay away from the CLI - and set up a web-based GUI to admin the server - here are four CLI commands :-) to achieve that:
# sudo echo "deb http://download.webmin.com/download/repository sarge contrib" >> /etc/apt/sources.list
# wget -q http://www.webmin.com/jcameron-key.asc -O- | sudo apt-key add -
# sudo apt-get update
# sudo apt-get install webmin
(probably another 2-3 minutes for all these steps to complete)

That's it. You now you have a full-powered LAMP server, configurable via a web GUI.

Total work? About 30 minutes.

Barring security concerns (firewall rules and following guidelines on apache/phpbb3 config, passwords etc), backups, and future updates (which Ubuntu will handle almost completely automatically for you), that's about all you need.

If you want to have a general purpose full-featured Linux server distro that will be easy to set up and maintain, and be flexible enough to adapt to any purpose, choose either Ubuntu or CentOS (the Redhat clone).
They are easy to work with, and both can do everything.
(I'm guessing you're going to be physically sat at the computer while you're working on it, or working over VNC or some such, and that therefore you'll want a GUI - in this case use the usual Ubuntu desktop installer (rather than the -server edition which contains no GUI stuff).

Otherwise, if you want a quick and easy route to LAMP web serving, then the above suggestions of XAMPP, Zend, and also possibly Bitnami are the obvious choices. (They don't necessarily involve Linux though.)

Personally, I would recommend Ubuntu. It is a cinch to install and set up, great active community support, and you're not limited in what you can do.

Here's a little demo of what setting up LAMP on Ubuntu would look like. You can get where you want to be pretty quickly:

- download and install Ubuntu to the server (installation could be 10 minutes)
- open a terminal and type:
    # sudo apt-get install apache2 mysql-server phpbb3
(this will take probably 2-3 minutes to complete)

You are now 90% set up with your LAMP server. Current versions of Apache, Mysql, PHP, phpbb3 and all their specific dependencies are now installed AND running.
Time to configure the services!

If you want to stay away from the CLI - and set up a web-based GUI to admin the server - here are four CLI commands :-) to achieve that:
# sudo echo "deb http://download.webmin.com/download/repository sarge contrib" >> /etc/apt/sources.list
# wget -q http://www.webmin.com/jcameron-key.asc -O- | sudo apt-key add -
# sudo apt-get update
# sudo apt-get install webmin
(probably another 2-3 minutes for all these steps to complete)

That's it. You now you have a full-powered LAMP server, configurable via a web GUI.

Total work? About 30 minutes.

Barring security concerns (firewall rules and following guidelines on apache/phpbb3 config, passwords etc), backups, and future updates (which Ubuntu will handle almost completely automatically for you), that's about all you need.

I run a few sites with equal or slightly larger audiences as the questioner. My servers are evenly split between Ubuntu server and Debian. A few things to note:

1. Don't be afraid to go headless and learn the bit of shell commands you'll need to know. You'll need them at some point anyway. Besides, most web-based packages you'll be using these days can be administered with either a web-based interface or an administration app. eg. For administering sql servers I use Sequel Pro on my Mac and connect over an ssh connection. Also definitely look into installing Webmin http://www.webmin.com/ - it definitely eases admin responsibilities.

2. Debian-based distros are all easy to find help for. As the parent mentioned Ubuntu has some of the best support out there, but even if you choose Debian 99% of what you'll find on Ubuntu-specific forums will apply. LTS Ubuntu server is rock-solid, easily as stable IME as Debian. And although my desktop systems have switched to Deb lately due to the recent odd GUI-related decisions of Canonical, these issues haven't spread to the base distro.

3. Administering any system is a learning process. If someone tells you that it's problem-free if you use X and Y they're lying. Expect a bit of a learning curve.

If you're going to be learning it, may as well learn it the correct way. CentOS (short for Community ENTerprise OS) is great for servers, and LAMP on red-hat based systems takes about two minutes to install and configure. Any Linux distro will be hard to learn at first, and CentOS isn't any harder than the other big names. Keep this in mind as you struggle through learning the command prompt. If you end up liking CentOS, you could try Fedora for a workstation to really lock down the Linux essentials. If you end up hating CentOS, you could try Ubuntu. Which brings me to the "avoids CLI" comment. While GUIs are nice and all, honestly, the CLI is much simpler. Even if you don't know what you're doing yet, you can copy-paste commands from guides and get things setup rather quickly. I'm not sure I've ever setup much of anything in Linux without use of the CLI. To give you an example of CentOS installing a LAMP server using YUM (package manager), you would type this at the command line: yum install httpd mysql mysql-server php php-mysql Now you have Apache, MySQL, and PHP all installed. If you want phpmyadmin, just throw "phpmyadmin" to the end of that line. If you really want to avoid the CLI, you can install "webmin" as well. It's worth looking into, at least: http://www.webmin.com/demo.html And then to start the services: service httpd start service mysqld start If you want these services to run every time at boot: chkconfig httpd on chkconfig mysqld on Everything will be running, and will startup with reboots. Your website will be located at /var/www/html and directory read/write permissions should be set to the new user, "Apache". See how short and simple that was from the CLI? It was five commands! Anyway, I digress... Some people have suggested Ubuntu, but Ubuntu isn't a server distro. It will work, but if you want to run a stable server from a Debian standpoint, you would probably use the original: Debian. I don't recommend this, however, because Debian can be a PITA, if memory serves correctly. A lot of people out there will try to tell you that Ubuntu can be, and is, used for servers. Well, it's true. Anything can be used for a server, and there are quite a few Ubuntu servers out there, but that doesn't mean it's right. I mean, deep-fried Twinkies are still food, but that doesn't make them /proper/ food. If all this distro talk is going a little over your head, I wrote an article a while back as part of a series I never finished, introducing people to Linux. It's short, but you may find this section useful: http://drprofessor.info/index.php?option=com_content&view=article&id=151:a-brief-history-of-linux-and-distros&catid=50:linux and this one, too, if you want to know more about the directory structure differences between Linux and Windows: http://drprofessor.info/index.php?option=com_content&view=article&id=152%3Adirectory-structure&catid=50%3Alinux&Itemid=449

For Linux, I'm a big fan of Webmin, I've been using it for many years now as a Linux server admin tool, I even use it for a few things on Mac OS X Server.

For some things, the command line is ok, but I really prefer a well-designed GUI. The 10.6 admin tools weren't amazing, but nearly good enough - the 10.7 tools are significantly less powerful, and for some things the interface is just absolutely painful.

You mention the IT department - in my case, I am the IT department - for multiple small/medium size companies. Most of them are either all-Mac or mostly-Mac shops, including travel, law offices, medical practices, ad agencies, even retail. I'm not sure what size an all-Mac shop would need to be to actually need a full time IT person - maybe a thousand users?

Ever see an NFS server not work because the config file had a space instead of a tab?

That's what we call bad design. Bad design can and has severely screwed up GUI interfaces as well. You had to specifically choose NFS because you are no doubt aware that the vast overwhelming majority of text config files do not care about whitespace and would not have this problem. This is an instance of the exception that proves the rule. It actually weakens your case when this is put into perspective.

How about something not working because you picked two options that conflict with each other? A gui would not allow that.

A CLI won't allow that either -- you'll get an error message when you run the program with a faulty config file.

Thankfully apache split httpd.conf into multiple files because it was getting several thousand lines long.

More cherry-picking that doesn't represent the majority of command-line tools. You have an opinion and I get that. The need to validate it by cherry-picking only those examples that reinforce it is known as confirmation bias. It'd be a lot more intellectually honest to acknowledge that what you have is a mere preference, that others are not bothered by the things about which you raise objections. In fact, others downright like them and think you're perfectly entitled to agree or disagree with their tastes.

Apache is a versatile daemon that can do many different things. There are GUI tools both commercial and open source that can configure an Apache server. Webmin is a free open source tool that can do that among many other things. Apache-GUI is a commercial tool. There are others beyond those two examples. If you are editing the Apache config files with a text editor on the command line it's because you are choosing the method that suits you.

Incidentally a long config file doesn't bother me. Hitting page down a few times is a similar amount of work to me compared to closing the file I'm working on and loading the next one in the text editor. The search function of any decent text editor is how you jump to the section you want instantly. I'll add that most users don't need to tweak every possible option of a complex daemon. Many times, you can use a small config file containing just the options you need. The long-form config files provided by default tend to be configuration examples for reference, with the majority of the content being comments to document them.

A gui could have all those options in a few tabs and a hovering help box if you really wanted.

And if you really want, you can normally use a GUI that ultimately produces the same text config file you could have also made on the command line with a text editor. Most common programs have at least one available; many have several from which to choose. You still retain all the advantages of a human-readable text file that can be easily backed up, can be easily edited if something happens to your GUI or it is unavailable (i.e. an SSH session that doesn't have X), can easily be copied to other systems when you need to replicate settings, etc.

Yeah yeah scripting blah blah, multiple setups, how about taking a screenshot of the gui?

If the GUI could accept that screenshot as input and automatically check all the boxes for you, so that the GUI now matches perfectly the contents of the screenshot, that might be useful. Otherwise you're back to doing it manually and you're back to doing it the way you prefer -- CLI or GUI.

Use whichever one floats your boat. Really. I won't try to stop you. I don't need to feel secure about myself by converting you to my way of doing things. That's why I don't need to pretend like my way is

I've been working for weeks toward setting up a test box for Xen (I want to learn it for work). In my research i found the webmin-related product cloudmin which works for both Xen and KVM. Haven't tried it yet, hopefully it's as good as regularly webmin. That'd provide the GUI, not sure about the other stuff.

Hope the following helps with your issues: Client / Server: Each of the workstations can be set up to "phone home". Select the "Webmin Servers Index" option

- View client computer status: "System and Server Status"

- On/off, sleeping etc.

- Deny internet access, not LAN, just the web: "Webmin Users", can schedule time

- Block access w/Squid

- Remote virus scanning of client machines, or scheduled task;

Unnecessary if you'll put a basic Linux distro on the clients

- Some kind of hardware monitor, high temp / fan speed low etc "Hardware"

- Email alerts for various log files / alarms. "Monitoring"

Hope that helps. It's not even a steep learning curve, and you get to ignore the viruses and adware they were going to pick up anyway.

I recommend Webmin which 100% FOSS. I have found it reliable, flexible and feature-rich.

I recommend Webmin also, I have a webmin cluster for all the centos servers to manage packages, run cron jobs, shell commands etc. I have setup another cluster webmin server to look after all ubuntu (can be on same server, but easier to amange) systems.

I recommend Webmin which 100% FOSS. I have found it reliable, flexible and feature-rich.

I am a teacher with a lab of about 20 workstations running Ubuntu 8.10.

I installed Webmin on the workstations and my computer and use the clustering features. I use likewise-open for AD authentication and Webmin for everything else.

You can create a policy template by configuring one workstation and copying the gconf.xml.mandatory to the administrators workstation. All you have to do then is use the cluster file copy in Webmin to push your xml file to your clustered workstations. It works for me anyway.

I also recommend Cluster SSH for some tasks that require a shell. CSSH works just like SSH but allows you to send a single command to every machine in the the group simultaneously.

Locking Down
Webmin
CSSH

I haven't done anything with SAMBA in a few years, but a few years ago, the best thing I found for configuring SAMBA was Webmin. I found the SAMBA config files baffling, but Webmin gave me an easy GUI.

http://www.webmin.com/

The situation where Firefox 3's new policy is most annoying is installable applications that use a browser-based UI with SSL. The one closest to my heart is Webmin, which will run in SSL mode by default if the needed Perl libraries are on the system when you install it.

When installed, it generates a self-signed cert unique to the system, with * as the hostname in the cert. This used to work fine - browsers would display a security warning when you connect, but this is expected and covered in the documentation. Sure, there was a risk of MITM attacks the first time you logged in, but having some encryption is way better than none at all, especially for an app that has root access to your system.

Also webmin/virtualmin..

http://www.webmin.com/virtualmin.html (free/gpl)

and its commercial 'pro' version..

http://www.virtualmin.com/

Perhaps because Apache httpd is really targeted at network and server admins, not people who want to run just one website on their home computer.

That said, in RedHat-flavored distros the answer is easy. Delete or move the files in /var/www/html and replace the contents of that directory with your website. That's it.

Now I'd put my website in a directory under /home/myusername and add a file to /etc/httpd/conf.d to define a virtual host. But I've been using Apache for a dozen or so years now, so I'm pretty comfortable with the contents of httpd.conf.

For people just starting out with Linux who need to do server administration, I often install Webmin, a web-based graphical front-end for system administration. For people more comfortable with GUIs than the command line, it can often make things much easier.

I like the look of Usermin for Webmail ( http://www.webmin.com/uwebmail.html ), but I may be biased because I created it ..

The real question is: how much of the maintenance can be done remotely? Being a Linux distro, I have to imagine that most, if not all, of it can.

They missed Webmin... http://www.webmin.com/

Can simplify management tasks quite well for Windows, Mac, Linux, and most other flavors of Unix...

• ...is a great abstraction layer for iptables, so writing your firewall policies and rules is more like writing them in English* than straight iptables (although you'll still want to understand iptables enough to debug problems);
• ...uses a modular config, including "macros" for commonly-used rulesets;
• ...allows you to set arbitrary variables, like $WEBSERVER or $ALL_PRIVATE_NETWORKS, which make your rules all the more natural-language-like;
• ...gives you an elegant "did I just compose a firewall that's going to lock me out of the box?" sanity check ('shorewall safe-start' or 'shorewall safe-restart');
• ...offers excellent advanced features like multi-ISP use and integration of bandwidth shaping (using 'tc') in a satisfyingly-straightforward way;
• ...and manages to put firewall admins "on rails" without sacrificing advanced capabilities (see above).

* I have no experience with its internationalization.

No, I'm not on the Shorewall devel team. ;-)

It's just a set of scripts, so it should run on any system that offers iptables and an sh-compatible shell. There are prebuilt packages ("noarch" RPMs, for instance) maintained for most major distros.

Coupled with Webmin (for which there is a Shorewall module available) and add-ons like OpenVPN, Squid, and DansGuardian, this makes for a pretty capable "edge box" that even "non-Unixy types" can manage, provided they understand the OS-independent aspects of firewall management...

(No, I'm not on any of those devel teams, either.)

I have set up and supported remote sites and home based telecommuting. Listen to my advice, listen very carefully and save your sanity.

If your organization is large enough then it is likely that you will have a few older desktop PCs that have been or are due for replacement during an upgrade cycle. PCs that are inadequate for Microsoft XP and Office2003 are more than powerful enough for many current versions of Linux, especially for the role of server. Also second hand PCs with the required specifications are very cheaply acquired.

1) Find an older PC, at least a PII 300 with 256 MB memory, to set up as a headless ( no display or keyboard ) server and firewall. A simple web based interface ( or even an external hardware push button ) can be used by the local users to start/stop the server and internet connection. All other maintenance should be handled remotely via ssh, webmin and VNC.
2) Install a second NIC or connect the modem directly to the server. Connection to the Internet should be through the server and connection to the Office should be through a VPN on the server. Use a dynamic IP service for each site so you can remotely log on to the local server via ssh.
3) Install a new IDE hard drive in a 3.5" removable rack and tray. The drive should be than big enough for the operating system (Linux of course) and copies of some of the local desktop partitions. A telecommuter can shut down the server and bring in the drive during the day to resync and repair.
4) Install a DHCP demon on the local server to allocate local IP addresses, DNS and gateway settings. If the desktops are network boot capable then install TFTP to remotely boot and use Knoppix via PXE and the network. If the desktop OS is constantly crashing, or is infected by malware, the user can select PXE/network boot via the BIOS, and boot into Knoppix. The user can then be instructed over the phone to enable the ssh server to allow remote scan,repair and reimaging of the desktop partitions. The user can use the Knoppix desktop to continue working with full access to files while the the remote administrator fixes/reimages the drive in the background.( Consider hiring someone who knows how to customise Knoppix or another live Linux system for your setup )
5) Partition the desktops with as small as required C: partition ( or in the case of Linux the root partition ) for software. When software is install, use dd and netcat via live Knoppix to copy/clone a snapshot of the partition to the server. You can allocate the remaining free space as a persistent partition where documents are stored.
6) Install and enable remote VNC service on all the platforms, but only allow incoming connections from the local server ( which is redirected over a SSH tunnel ).
7) For local backup, create share directories on the desktop accessible by the server. On the local server create loopback encrypted file systems, unmount and copy the images to the desktops shares in chunks, using redundancy if enough space is available on the desktops. Checksum ( MD5 is enough ) each piece.
8) If the network load to the Office is taking up all the available internet bandwidth or the connection is just too slow then install proxy servers on the local server. You can also consider using a distributed filesystem ( OpenAFS is still the best ) wi

You seem pretty happy having made the switch. Let me toss out some advice about some of the issues you raised.

Configuring a dual-boot system took me 4-6 hours to figure out, setting up the right partitions (making sure nothing on my windows partitions got erased) took me wayy too long (screwed it up twice).

Configuring dual-boot on a single-drive system is hard. Installing a second drive makes the task much easier. Move the Windows drive to the secondary, install the new drive as the primary, install Linux. When I did this with Fedora it detected the Windows partition on the secondary drive and set up dual-boot for me without a hitch. I didn't have to play with the partitioning of the Linux drive either; I could just accept the defaults.

Figuring out how to move from firefox 1.5 to firefox 2.0 was surprisingly difficult. I don't really understand why that particular thing isn't part of the yum update process but that's just an outsider's perspective.

Most distros take a snapshot at release time and update that software throughout the life cycle of the distro. Firefox 2.0 will be in Fedora 7, but Fedora 6 will continue to stick with 1.5.x until FC6 reaches end-of-life. That's a good decision from a support perspective, but problems can arise as you discovered when you try to update something directly from the developers rather than through the distro's package-management mechanisms. Hell, the Linux kernel in things like RedHat Enterprise 4.4 is still around 2.6.9 while the current kernel release version is 2.6.19. The RHEL kernel is heavily patched to keep up with security fixes, etc., but it's still fundamentally 2.6.9 which shipped quite a few years back now.

I haven't figured out Samba yet--this seems like it should be easy but so far it's not.

I often install webmin, a web-based administrative tool. You can install this with "yum install webmin" if you have the "extras" repository enabled. Afterwards, use a browser to open https://localhost:10000/, and log in as root, and you'll have access to a very nice and ever-growing collection of graphical Linux management tools. (You might want to change the default webmin admin account or the webmin port if you're concerned about local security.)

This is much simpler way to configure Samba if you're not used to editing config files. You do have to set up separate user accounts in Samba, but after doing that, all you need do is issue two commands at the prompt (as root):

#chkconfig smb on
#service smb start

The first tells the machine to start Samba upon reboot; the second starts the server right now. Once nice feature of having separate accounts for Samba is you can use a Windows login that doesn't match your Unix login. For instance, I have the same username in both cases, but different passwords.

There are GUI tools that you can use for service management, but I prefer to use the command-line for simple tasks like this.

For 3 and 4, sounds like Webmin would be good option for you, if the built-in distro tools (RH, SuSe, etc) don't cut it for you.

You mean like this or
webmin anyone? or
this if you want a non-web version

Have you tried webmin? You'll find it make Linux boxes much easier to manage, possibly as easy as Windows

I'm curious what people who've gone the DIY route are using to ease the management hassle that I could easily see a SAN becoming if it's OS is just straight Linux.

I'd guess Webmin

Webmin is open and extensible, if you really need a control panel of some sort, I can't see why you would use anything else.

http://www.webmin.com/

It already controls many many more things than any of these so called control panels.

The 3rd party modules are pleantiful as well.

Regards

1) Webmin
2) Webmin
3) Webmin
4) Webmin
5) Webmin
6) Webmin
7) Webmin
8) Webmin
9) Webmin
10) Webmin

http://www.webmin.com/

Many of those modules are really useful.

"Also, while there are some GUI configuration tools for apache from various sources, all of them suck rocks through a straw to the point that it's EASIER to look up arcane flags and configuration settings and type them into a text editor than it is to click a button."

While I'm probaly not the best judge since I think Apache is easy to set up (the 'arcane flags' are documented in the comments in the config file), I found webmin makes a nice and usable GUI for Apache.

YaST is precisely one of the reasons SuSE has not been more commercial. As pretty as it is, it's really an undocumented collection of insonsistently written interfaces under the hood, and it breaks things very badly. For example, its chroot handling for BIND and DHCP is a bad joke: you do not intermingle the contents of a chroot tree with the directory it's copying the files from, and you do not make the system files symlinks *out* of a chroot tree. You move the files and make the symlinks *into* the tree. The autoyast tool can't look at update locations and base repositories at the same time, so solving dependencies for new features can accidentally revert core packages and break your system.

The insistence on re-arraning configuration files in ways that software authors never dreamed of makes the systems unstable if you try to upgrade to a new version of the software, such as the insistence of filling the kernel SRPM's with tarballs of bundled patches instead and managing those with a shell script run by the .SPEC file, instead of actually putting them in the .SPEC file and as separate patches like any sane system. Their factoring of their packages is very bad, and the cutesy little tricks they play with their SRPM's making them rely on packages that are not part of the distribution but exist only in their build environment make development quite hard. Coupled with the fact that autoyast demands a user at the console to do updates, and you get the sorts of reasons I got a 500 machine site to throw it the heck out and switch directly to CentOS.

And don't get me started on the NVidia driver craziness: do *not* weld shell-script installed packages into an RPM manager, because they're distinct beasts and will step on each other.

YaST is where Linuxconf from RedHat was 4 years ago: you many notice that RedHat dumped it and now makes smaller, more modular, and consistently good configuration tools that are much smaller and easier to modify for new features. If you need to admin a SuSE box, install http://www.webmin.com/ and http://fou4s.gaugusch.at/ for package management and you'll have a much more usable system. If you want more up-to-date or non-DRM crippled tools, go to http://packman.links2linux.de/.

One of the most useful remote admin packages out there. Especially useful for those just getting into Linux/Unix. Want to install a Perl module? just select or enter the name. Wanna change a cron job for a user, it's in the Cron screen.

http://www.webmin.com/

1) Install a second NIC or connect the modem directly to the server. Connection to the Internet should be though the server and connection to the Office should be though a VPN on the server.
2) Install a new IDE Hard drive in a 3.5" removable rack and tray. The drive should be than big enough for the operating system (Linux of course) and copies of some of the local desktop partitions. A telecommuter can shut down the server and bring in the HD during the day to resync and repair.
3) Install DHCP demon to allocate local IP addresses, DNS and gateway settings. If the desktops are network boot capable then install TFTP to remotely boot KNOPPIX via PXE. IF the desktop OS is constantly crashing, the user can select PXE boot, network KNOPPIX. The user can then be instructed over the phone to enable ssh server to allow remote repair and reimaging of the desktop partitions from copies on the local server.
4) Partition the desktops with as small as required C: ( or in the case of Linux the root ) partition for software. When software is install, use dd and netcat via live KNOPPIX to copy a snapshot of the partition to the server. You can allocate the remaining free space as a persistant partition where documents are stored. ( Consider hireing someone who knows how to customise Knoppix for your setup.)
5) Install/Enable VNC on all the platforms, but only allow incoming connections from the local server ( which is redirected over a SSH tunnel ).
6) For local backup, create share directories on the desktop accessable by the server. On the local server create loopback encrypted file systems, unmount and copy the images to the desktops shares in chunks, using redundantcy if enough space is available on the desktops. Checksum ( MD5 is enough ) each piece.
7) If the network load to the Office is takeing up all the available internet bandwidth or the connection is just too slow then install proxy servers on the local server and consider using a distributed filesystem ( OpenAFS is still the best ) .
8) If phone charges are eating into the budget, and the internet connection is good enough, then install Asterisk on the local server ( upgrade the server to a Celron 800Mhz or better ) and a card with enough FXS ports for each local user. Don't bother with software based phones/headsets. The phone will work when the desktop does not.
9) Set up a Linux server at the Office that operates as a thin client application server. Allow remote access though both FreeNX and VNC. Create login accounts and logins that operate as virtual meeting rooms, with multiple users logging in via VNC. Use VNCserver with a screen size of around 1000x600, that will operate via a VNC viewer on any 1024x768 desktop. Use phone based conference calling for voice -- it's a lot less hassle for the users
10) Add the ususal list of cross platform applications: Firefox, Thunderbird, Gaim, OpenOffice etc.

Do the open ten step and save yourself and your santity from all those hours driving from site to site.

Enterprise = support

GUI,

proper QA and release procedures

Ideas...
Ahh, well, they're already one step ahead of you on these things :-)

1. How bout a hardware based SSH accelerator for fast SFTP/SCP transfers?

http://www.openbsd.org/cgi-bin/man.cgi?query=ubsec &sektion=4 (as far as I know, hardware crypto accelerators are automatically taken advantage of for OpenSSH/OpenSSL applications)

2. GUI configuration in X/QT/GTK...ect...
http://www.webmin.com/standard.html webmin - has all the pretty check-boxes and drop-down combo lists you need. There are probably other solutions besides webmin that you can use.

3. Performance monitoring tools
Erm... top? I don't know what performance parameter you need to monitor. The OpenSSH scp client already gives you a transfer rate.

Moral of the story: Like many other unix things that are Good (tm), OpenSSH doesn't have to be all things to all people... one app that does one thing and does something well is the "unix" way. It's quite trivial in most cases to expand functionality by taking advantage of the modularity of these things.

Having said that, OpenSSH really does quite a lot of stuff.

A meta-configuration tool? No...that's just spin. This is just a (almost isn't) package manager that includes a scheduler and a template engine.

It doesn't look like it does anything you can't do with cron, rsync, your package manager and the scripting language of your choice easier (because you can get more features and support from the combination). Why would anyone actually need this?

Silly indeed. If you're looking to actually manage OpenSSH and most of the actual system tools without actually having to write that configuration tool (and you want to do it through a GUI), then you want something that can read and write configuration files.

For that there's the old linuxconf or webmin. Of course a lot of distros feel inclined to make their own stuff.

You can always use webmin.

However, something that comes with most Linux distributions, Webmin, manages Apache just fine, so you don't have to 'download' anything.

Which is why I asked if you were brain damaged. While Apache may not provide a GUI config tool, either does IIS6. They both just use the OS's configuration tool, Webmin and the MMC respectively.

As an added bonus, of course, you can access Webmin from any sort of computer, as it's posing as a web server. Whereas MMC can do remote access, but only from other Windows machines.

Sadly, if you're running Apache on Windows, support for Webmin on Windows is still very beta. (Webmin is just Perl.) Here it is if you want to risk it.

Apache on Windows has always been a bit of a joke anyway, though. If you run Apache in its intended enviroment, a Unix or Unix-like system, Webmin works fine. If you run it on a Linux system, Webmin is usually already installed.

Of course, in your hypothetical world where the Apache devs also decided to write a UI, it would be for X, and thus difficult to run on Windows in the first place.

Hello, Very nice firewall http://www.shorewall.net/ and it has a GUI on webmin, http://www.webmin.com/ run it on any Linux Distro Ihave it since 2 years, and im so happy with, and the community beyond it is very active Good Luck Kind Regards Samer

If I have never have to use vi to set up a simple routing configuration again, it will be WAY too soon. If I can't point and click my way to a basic setup, it's not a useful system
you forgot the "for me" here
, and comparing it to something that can do that is ridiculous.
BTW http://www.webmin.com/
http://www.janoschka.net/webmin/Clipboard.gif

I've used the CUPS interface on RH9 and FreeBSD 5.3 without problem for an admittedly small variety of printers. While it's not the most intuitive, it wasn't difficult.

My Win2000 and WinXP boxes don't seem to have trouble connecting via SAMBA.

Though I used the CUPS interface to set up my *nix boxes, I have been using Webmin for certain other purposes. (Yeah, so I'm a weenie for not doing everything with conf files...) So, I checked the Webmin interface in /Hardware/Printer Administration and found it semi-clean. Except for needing to pre-install some print drivers manually, it looks like it should be relatively easy.

Maybe I don't know what I'm talking about.

I've heard recommended:

http://www.vhcs.net/vhcs/

and

Virtualmin + Usermin

I've heard recommended:

http://www.vhcs.net/vhcs/

and

Virtualmin + Usermin

Have a look at Webmin. It is really remote administration and not as powerfull as Zenworks. However for a small business you may find that it does what you need.

I personally don't use Webmin or any similar product. But I have never had to manage more then a dozen machines. I know of Webmin as it has been around forever and it is still being developed.

Note: like all remote administration tools, includeing Zenworks, Webmin does add a security risk. However the risk is easy to manage if you read the docs and configure Webmin properly.

For you, probably nothing. For a larger business it would be worth it, as it comes with "Apple style" GUI tools to configure everything, and a lot of stuff built-in.

Assuming you have a familiarity with Linux, or any command line really, you can get yourself up and running with a standard OS X 'client' based machine. I'd suggest installing Webmin on your box to help configure things. I've got Webmin running on two of my OS X machines and it makes configuration really simple by adding web-based remote administration to many many tasks (Apache, BIND, Squid, Webalizer, remote access to the file system, etc) while still giving you the ability to edit the raw config files if you want.

You may also want to install Fink to help you get some of the services that are not installed by default in there. (For example Apache is in the OS X client, it just happens to call it "Personal Web Sharing" in the GUI, but their is no POP3 server built in)

I believe the Java security warning only appears if the application wants to run outside of the sandbox. Thus, clicking OK on that security warning will allow the applet to access your hard drive.

For example, BroadbandReport's speed testers don't show a security warning, since they don't need full access. On the other hand, the file transfer utility on a Webmin server does show a security warning, since it needs to access files on your hard drive in order to upload or download files.

In short: Don't click "YES" on any unintended security warnings, regardless on where they came from.

Trusted Build Agents are the final twelth step in my Twelve Step TrustABLE IT blog entry.

Also is already possible to secure Linux desktops the "right way"

(#75791 by guest NZheretic in response to Mainstream means more malicious code for Linux (SearchSecurity.com).)

On Windows, most of the viruses are e-mail borne. On the Linux side, today and in the future, viruses are network-aware, and [they] take advantage of vulnerabilities in networks or systems to infect machines. The Slapper worm, for example, attacked vulnerabilities in OpenSSL and Apache.

I have deployed Linux on the desktop (RH8+Ximian to RH9+StarOffice) in an enterprise and they do not suffer from such problems for long.
1) The only network service the desktop systems expose is OpenSSH and the Iptables limit access from only three addresses.( We use a custom script with ssh to keep the systems rpms uptodate from a private mirror).
2) The iptables are configured to allow the desktops client services to connect only to the specified server.
3) The /usr partions are mounted read only and the /tmp, /home, /var directories are mounted non executable.
4) None of the users have, or need, root access. They have access to printer setting etc via Webmin's Usermin which runs on a dedicated server.
5) Mounting the users home directory required shares etc ( we use Samba for domain, file and print services ) is performed by script when the user logs in.
6) We update all the desktops within minutes of a updated RPM package becoming available. The window of opportunity for any disclosed vulnerability is very small.
7) We schedule Tripwire to check the intergrity of the desktops a couple time a day.