Hi,
So, currently we have two login servers, one which runs Linux and one which runs Solaris. This greatly complicates system administration (as everything has to be done twice), and confuses users, since things are different between the two login servers, and between the Linux login server and the web server.
Since deploying the Solaris login server (willow), we've made quite a few changes to improve the user experience for users coming from Linux, to the point that I think most users would not have a problem using the Solaris servers.
With this in mind, it might make sense to dispose of the Linux login server entirely, and convert it to Solaris. But before we consider this, I need to know if there's anything still missing from our Solaris environment which compels users to use the Linux server instead.
So: if the Linux login server were to go away tomorrow, what (if anything) would you miss?
- river.
Il giorno 28/dic/2009, alle ore 18.08, River Tarnell ha scritto:
With this in mind, it might make sense to dispose of the Linux login server entirely, and convert it to Solaris. But before we consider this, I need to know if there's anything still missing from our Solaris environment which compels users to use the Linux server instead.
So: if the Linux login server were to go away tomorrow, what (if anything) would you miss?
Just a question: why is Solaris more suitable for us than Linux?
"I'm Outlaw Pete, I'm Outlaw Pete, Can you hear me?" Pietrodn powerpdn@gmail.com
It's easier for the admins to maintain Fahad Sadah
2009/12/28 Pietrodn powerpdn@gmail.com
Il giorno 28/dic/2009, alle ore 18.08, River Tarnell ha scritto:
With this in mind, it might make sense to dispose of the Linux login
server entirely, and convert it to Solaris. But before we consider this, I need to know if there's anything still missing from our Solaris environment which compels users to use the Linux server instead.
So: if the Linux login server were to go away tomorrow, what (if
anything) would you miss?
Just a question: why is Solaris more suitable for us than Linux?
"I'm Outlaw Pete, I'm Outlaw Pete, Can you hear me?" Pietrodn powerpdn@gmail.com
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09-12-28 01:03 PM, Fahad Sadah wrote:
It's easier for the admins to maintain Fahad Sadah
Which admins? I know River is very experienced with Solaris - but are the other sysadmins more experienced with Solaris than linux as well? If not, it may still make lots of sense to move to Solaris because of River's expertise. Then again, what happens if a bus comes along and we then have admins who know linux best? In the end, I'd imagine this is something for them to decide amongst themselves. I just like to see my own typing :P
- -Mike
On Mon, Dec 28, 2009 at 3:13 PM, Mike.lifeguard mike.lifeguard@gmail.com wrote:
Which admins? I know River is very experienced with Solaris - but are the other sysadmins more experienced with Solaris than linux as well?
No. All of us except River are more experienced with Linux. However, River does more work than the rest of us combined, at least of the sort that's platform-dependent.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09-12-28 03:22 PM, Aryeh Gregor wrote:
No. All of us except River are more experienced with Linux. However, River does more work than the rest of us combined, at least of the sort that's platform-dependent.
Long live the <s>Queen</s> lead sysadmin :P
- -Mike
On 28/12/2009 08:13 PM, Mike.lifeguard wrote:
Which admins? I know River is very experienced with Solaris - but are the other sysadmins more experienced with Solaris than linux as well?
We had a long discussion about this in the admins IRC channel... we all agree that having two separate OSs in the platform is bad, and that either everything should run Linux, or everything should run Solaris. So the only decision is which OS we should use.
(A third option would be to ditch both Linux and Solaris and move to another platform entirely... while I'm always looking for alternative solutions to consider, this is very unlikely to happen any time soon, so it's irrelevant to this discussion.)
From my point of view, there are three distinct admin tasks which are regularly needed for the TS. The first is general housekeeping; monitoring servers, killing errant processes, and so on. There is little difference between Linux and Solaris here, so we can ignore that.
The second is software installation. Debian has a large pre-built repository of software, while for Solaris we maintain our own packages, which means new software has to be built and packaged for installation. (Which is usually fairly simple, but takes a bit longer than running "apt-get".)
I don't see this as a particularly critical issue. Even if I end up having to build all the software myself, it won't add a significant amount of work to my existing workload.
The third issue is more intricate maintenance and debugging work needed to keep the system running. This includes things like network installation profiles to allow reproducable server configurations, through performance tuning, OS patching, etc.; and debugging: MySQL, for example, is a complicated piece of software with many subtle interactions with the OS, and maintaining it requires good knowledge of both the OS and MySQL itself.
At the moment, the vast majority of this sort of work is done by me, which works because I have a good understanding of, and real-world experience with, the operating system we use (Solaris), and also experience using Solaris with the other software we use. On the other hand, I rarely use Linux, and have no experience of using Linux in complex systems like the Toolserver, or with MySQL.
Obviously I can install a Linux system and run MySQL on it, but the moment we run into some subtle operating system issue interaction or performance issue with MySQL, it's going to take me a lot longer to fix it than it would if we ran Solaris. It therefore seems to me that if we moved to Linux, the overall reliability of the Toolserver platform would be degraded.
The obvious counter-point here is that if all systems ran Linux, even if I wasn't able to fix it, we would have a larger pool of admins with Linux experience who could. However, most of our admins have little time to spend on the Toolserver, and indeed some admins we've added in the past have effectively disappeared due to other commitments. Of the three currently active administrators other than myself, one is self-admittedly not an expert on either platform, and one has little time to spend on the Toolserver other than the work he already does, so that leaves one person with Linux experience. Moving most of the workload from one person to another person doesn't seem like any advantage at all.
One or two other people have offered their time to the Toolserver in the past, and have some amount of Linux experience, but given our experience with adding additional admins so far, I'm reluctant to keep adding people who disappear or only have time to perform housekeeping tasks; I'd rather wait for someone who can clearly commit a significant amount of time to the project.
Then again, what happens if a bus comes along and we then have admins who know linux best?
This is a valid concern, but if we used Linux, and our single active Linux admin was hit by a bus, we'd have the same problem. I hope there will be some changes over the next year or two which will make this issue moot... until then, I will try to avoid busses.
- river.
On Mon, Dec 28, 2009 at 5:15 PM, River Tarnell river.tarnell@wikimedia.de wrote:
Then again, what happens if a bus comes along and we then have admins who know linux best?
This is a valid concern, but if we used Linux, and our single active Linux admin was hit by a bus, we'd have the same problem. I hope there will be some changes over the next year or two which will make this issue moot... until then, I will try to avoid busses.
Anyone competent enough to maintain Linux systems to the extent and in the manners required here could also maintain Solaris and muddle through long enough to make the transition to their preferred platform.
River's continued survival is important for reasons unrelated to the system platform.
On 28/12/2009 06:02 PM, Pietrodn wrote:
Just a question: why is Solaris more suitable for us than Linux?
It's not really a question of "more suitable". The Toolserver has always been Solaris, mostly because I was the first TS admin, and Solaris is what I know.
The Linux server(s) were added as a concession to users who found Solaris hard to use, but I don't think that's necessary any longer, since we've made improvement to the userland on the Solaris servers.
- river.
2009/12/28 River Tarnell river.tarnell@wikimedia.de: (...)
So: if the Linux login server were to go away tomorrow, what (if anything) would you miss?
just VIM under "vi" command ;)
Ill take a look and log into willow tonight to see what if anything would break if I moved to solaris. Is there any particular place that we need to report these differences that may need adjusted or things need added?
Betacommand
On Mon, Dec 28, 2009 at 1:36 PM, Michał holek.n@gmail.com wrote:
2009/12/28 River Tarnell river.tarnell@wikimedia.de: (...)
So: if the Linux login server were to go away tomorrow, what (if
anything)
would you miss?
just VIM under "vi" command ;)
-- Michał "Hołek" Połtyn
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
On 28/12/2009 06:40 PM, John Doe wrote:
Is there any particular place that we need to report these differences that may need adjusted or things need added?
If you plan on actually using it, then file a request in JIRA. Otherwise the mailing list is fine.
If we ever actually decide to stop using Linux, there would be a separate migration period to identify specific problems. For now I just want to get an idea of what the problems might be.
- river.
On Mon, Dec 28, 2009 at 18:08, River Tarnell river.tarnell@wikimedia.de wrote:
Hi, [...] - river.
I have a tone of local compiled (xs) perl modules which will most certainly break, and I really don't know if I can magically convert my $HOME/.cpan to solaris without much great pain, also, have you installed all perl modules which where installed under linux? does they exists as packages or does most of them require "manual" install? Is solaris 32bit or 64bit? i.e. are the risk of breaking people relying on 64bit ints?
On 28/12/2009 07:00 PM, Carl Fürstenberg wrote:
I have a tone of local compiled (xs) perl modules which will most certainly break, and I really don't know if I can magically convert my $HOME/.cpan to solaris without much great pain
I see.
have you installed all perl modules which where installed under linux?
Probably not, unless someone requested them.
does they exists as packages or does most of them require "manual" install?
We never do manual installs of software, it's unmaintainable. For Solaris we have a well-developed system to build local packages.
Is solaris 32bit or 64bit?
It supports both. All Toolserver machines are 64-bit.
i.e. are the risk of breaking people relying on 64bit ints?
If you're talking about Perl specifically, our local Solaris Perl build is compiled as 32-bit, but has 64-bit integers enabled. For other languages, it depends; in C, for example, it isn't an issue, since you can just use int64_t. (Nearly all 32-bit systems, including Solaris and Linux, provide 64-bit integers even in 32-bit mode.)
- river.
On Mon, Dec 28, 2009 at 12:08 PM, River Tarnell river.tarnell@wikimedia.de wrote:
So: if the Linux login server were to go away tomorrow, what (if anything) would you miss?
A few things come to mind right away.
1) An easy-to-use compilation environment for C and C++. I am not really able to compile Perl modules on willow, despite spending quite a while hacking at it.
2) The version of script(1) that comes with solaris doesn't recognize the -f option like GNU one. This I did fix for myself, by downloading the source from opensolaris, changing it, and compiling. But I doubt that will be a popular option. In general, people who have only used linux might be more comfortable if you put more of the linux command line utilities somewhere, at least the ones that are not linux-specific
3) On the linux server, /bin/sh is bash. On the solaris servers, it isn't. Again, this is easy to work around for experienced people and painful for others. It would be a compatibility issue if scripts are moved from linux to solaris.
- Carl
Hello, Am Montag 28 Dezember 2009 20:28:56 schrieb Carl (CBM):
On the linux server, /bin/sh is bash.
that's even dangerous to suggest on the linux server. Debian made (and make) many changes in programs in the past to allow the default sh to be dash.
So there may be a time in future, when /bin/sh is dash. So if you need bash, use bash ;-).
Sincerly, DaB.
Am Montag 28 Dezember 2009 20:28:56 schrieb Carl (CBM):
On the linux server, /bin/sh is bash.
On Mon, Dec 28, 2009 at 3:04 PM, DaB. WP@daniel.baur4.info wrote:
that's even dangerous to suggest on the linux server.
I was not suggesting anything.
nightshade$ /bin/sh --version GNU bash, version 3.2.39(1)-release (x86_64-pc-linux-gnu) Copyright (C) 2007 Free Software Foundation, Inc.
On Mon, Dec 28, 2009 at 3:05 PM, River Tarnell river.tarnell@wikimedia.de wrote:
I wonder how many people this actually affects...
The following does not execute as a script under /bin/sh on willow, but does execute as expected in bash
export F=g echo $F
- Carl
On 28/12/2009 07:28 PM, Carl (CBM) wrote:
- An easy-to-use compilation environment for C and C++. I am not
really able to compile Perl modules on willow, despite spending quite a while hacking at it.
I know some people had issues with this but I never really saw a proper description of the problem (it's always worked okay for me)... can you give an example of a module that you weren't able to compile?
Apart from Perl modules, our standard Solaris build has two C and C++ compilers (GCC and Sun Studio), GNU make (which is invoked as 'make' with the default $PATH), and most other standard Unix development programs. Is there something in particular that's missing?
- The version of script(1) that comes with solaris doesn't recognize
the -f option like GNU one. This I did fix for myself, by downloading the source from opensolaris, changing it, and compiling.
We already have a backport of OpenSolaris' /usr/bin/ps to provide BSD-compatible syntax for Linux users. It shouldn't be a problem to install or backport additional GNU or Linux utilities.
In general, people who have only used linux might be more comfortable if you put more of the linux command line utilities somewhere
Yes - what I'm trying to find out is which utilities those are ;-)
- On the linux server, /bin/sh is bash. On the solaris servers, it
isn't.
I wonder how many people this actually affects... even on Linux, many systems have a /bin/sh which isn't bash, so any pre-made scripts should work okay. Most simple scripts should also work fine under Solaris /bin/sh. The most noticable missing feature is $()... this should be fixed in Solaris 11 (which replaces /bin/sh with ksh), but it's not exactly clear if/when that will be released.
- river.
On Mon, Dec 28, 2009 at 3:05 PM, River Tarnell river.tarnell@wikimedia.de wrote:
On 28/12/2009 07:28 PM, Carl (CBM) wrote:
- An easy-to-use compilation environment for C and C++. I am not
really able to compile Perl modules on willow, despite spending quite a while hacking at it.
I know some people had issues with this but I never really saw a proper description of the problem (it's always worked okay for me)... can you give an example of a module that you weren't able to compile?
Double-checking it, I was able just now to compile on willow the thing I can't compile on wolfsbane. It seems the dev environments on willow and wolfsbane are not identical, as I thought there were.
One advantage of moving everything to solaris is that it reduces problems caused by the webserver and the login server running different operating systems. This caused problems with self-compiled perl modules.
- Carl
toolserver-l@lists.wikimedia.org