[ If folks think this is too far off-topic, please say so: I think it's
relevant for people examing how to set up a server for Subversion. ]
----- Original Message -----
From: "Andy Levy" <andy.levy@gmail.com>
To: "Nico Kadel-Garcia" <nkadel@comcast.net>
Cc: <Steve.Craft@sungard.com>; <users@subversion.tigris.org>
Sent: Thursday, June 08, 2006 8:30 AM
Subject: Re: Look for help on windows server platform
> On 6/7/06, Nico Kadel-Garcia <nkadel@comcast.net> wrote:
>>
>> ----- Original Message -----
>> From: <Steve.Craft@sungard.com>
>> To: <users@subversion.tigris.org>
>> Sent: Wednesday, June 07, 2006 2:44 PM
>> Subject: RE: Look for help on windows server platform
>>
>>
>> > I'm not 100% sure why "linux as a subversion server is better".
>> >
>> > As far as I know, Apache==Apache, Subversion==Subversion, etc.
>> >
>> > Can someone elaborate on that?
>
> This is veering well off-topic, but a few points:
>
>> Security, since Linux has much b etter ability to turn unnecessary or
>> undesired services by simply never installing them.
>
> Windows 2003 has implemented a lot of "deny by default" features,
> especially with services. I haven't done a 2003 installation myself
> (only worked with it), so I can't speak to how many services are
> selectable in the install, but most non-essentials are turned off by
> default now. When I last installed Fedora Core, I had to go back and
> manually disable (at boot) a number of services it wanted to run by
> default.
There are still a bunch left: finding all the services to turn them off is
amazingly painful. And go ahead, try to turn off the read-write sharing of
C:$, which is carefully not mentioned as being exported by default if you
have Windows file sharing turned on at all, even if you try to set it up
only as a client. That is such a blazing level of stupidity that most other
shared resources pale in comparision.
>> Security, since Linux almost never requires rebooting to implement the
>> latest software or security patches.
>
> I don't see how required reboots translate to less security. Also,
> the number of reboots required is far lower than it used to be for
> Windows, and they can be scheduled for minimal impact on the users.
If you have to reboot to do an update, you have to wait until a safe time to
do so. For core servers, it may be days or even weeks before it can be
scheduled. This delays security updates. And it's very difficult to tell,
in advance, which Windows updates will require a reboot, so you can easily
wind up with a "I can't do the next security update because it's awaiting a
reboot for the last one." It's gotten better, but it is most certainly not
fixed.
Also, rebooting is one of the most likely times for a system to fail
altogether and should not be done lightly on a core server. On a desktop,
where downtime is less expensive, it can be a useful debugging tool. But on
a Subversion server, or a core server of any other kind? You do *NOT* want
to interrupt someone in the middle of a checkout!
>> Security, since tools like SSH and sudo allow much safer and easier
>> management of user accounts and administrative privileges.
>
> These facilities exist with Windows, it's a matter of administrators
> using them and applications not assuming you've always got Admin
> rights. Active Directory allows an insane level of control.
Which almost no one knows how to implement to that level, and thus winds up
badly setup and easily subverted. I've got stories and scars: we should talk
off the list if you're curious: the number of careless Windows admins who
just give their user accounts domain-wide "Administrator" privileges, simply
to deal with software installations or other system level operations on a
set of machines without having to log in as another user and wind up without
their bookmarks and profiles, is amazing.
>> Security, since the web and office suites tools on Linux are historically
>> far more secure than those for Microsoft.
>
> Office tools (and most other desktop applications) would have no place
> on a Subversion server in the first place, so I don't see how this is
> relevant.
You've never logged directly into the system to write the report, present
screenshots as part of a training document, walk other admins through core
operations, and to get cut&paste operations on the configurations to work
for your document? Or to run spreadsheets showing licenses or component
numbers? Or needed to open up the Word document or the calendar tools on the
server itself while doing the work they called for? Admittedly, some of the
Word viewers have gotten a lot better, and you can install OpenOffice or
StarOffice for better security of the actual tools. But you'd better believe
people use office suites on servers!
If not, you've had a lot better success with remote desktop tools and
writing documents with them than I've had.
>> Vastly easier duplication of a server setup to new or replacement
>> hardware.
>
> Tools exist for Windows to make a master image and "clone" it to set
> up multiple boxes quickly.
Yes, and they're notorious for not working well across even slightly
differing hardware platforms. The Windows registration itself constitutes a
serious problem for which there are workarounds, but they're painful. And I
dare you to image one Windows machine with a different SCSI controller to
another. It's fraught with adventure.
That's relatively easy iin Linux: edit /etc/modprobe.conf and /etc/fstab and
/etc/mtab, at most, for most such hardware revisions.
>> Less expensive hardware to run the server, allowing easy availability of
>> a
>> hot failover setup when coupled with the ease of mirroring a repository
>> under Linux.
>
> Hot failover and high availability hardware costs money regardless of
> your OS. What stops you from using the same tools to keep mirrors of
> a repository on Windows? Perl, Python, SVN, rsync, ssh, etc. all have
> Windows ports.
Yes, they do cost money. They tend to cost a lot *less* money with a modest
Linux setup than with the necessarily over-powered and expensively licensed
Windows setups, for which on various occasions I've successfully convinced
people to buy or repurpose one or for good failover, 2 modest hardware
platforms running Linux instead of investing in a much more expensive server
class Windows system.
Setting up the hot mirroring turns into a bit of an adventure for Windows:
my experience there is more with desktop mirroring, but rsync is nowhere as
fast and effective as I'd like under Windows, I assume due to the NTFS file
ownership fun and games.
> As for the later arguments of "remote administration" and
> "scriptability" lacking in Windows servers, those may have been good
> arguments 6 years ago. But not today.
How about last year? Seriously, there is a plethora of systems configuration
that is feasible in Windows only with a good GUI but which is doable in
Linux in very easy text-only editing or simple scriptable management tools.
These especially include package management, and oh-my-stars-and-garters
does it include spyware/adware/malware management.
I'm sorry, but sometimes a user of a server has to poke websites to get
software updates and look for relevant information about the software. For
Subversion, the websites are not adware prone, but for numerous sites they
are. Quite a few of them will actually screw up your DNS operations, and
those are nasty pieces of work to accidentally wind up with on a server.
It's a nasty world out there: Windows 2003 Server may be better secured and
gotten better than Windows used to be about these problems, but I wouldn't
compare it to a good UNIX or Linux system yet in the features I've
mentioned.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jun 8 16:49:57 2006