[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 31 Dec 2014 12:26:06 +0300
From: gremlin@...mlin.ru
To: owl-users@...ts.openwall.com
Subject: Re: owl-startup
On 2014-12-29 22:38:36 +0300, (GalaxyMaster) wrote:
>> In the abovementioned situation, I never asked anyone to take
>> my logs away and, more importnatly, I gained NOTHING I need,
>> only the trouble.
> I think you've missed the point: journald works _together_ with
> a syslog daemon. If you don't run a syslog daemon, then you have
> an option to have binary logs only (through journalctl), however,
> most people are using syslog daemons to get textual logs.
Looks like creating problems for fighting them later...
> I'm not forcing anyone, I just replied to your argument re:
> the stable and proved bootloader solution showcasing why other
> bootloaders are safer on a production system.
To be safe (just safe, not safer), the bootloader has to be simple
AND well documented. So, lilo and syslinux are safe, and grub isn't.
Yes, I'm glad to know we're using safe bootloaders :-)
> BTW, one of the reasons we included syslinux (in addition to
> making our ISO be a bit more modern) was that - it's just safer :).
"Make a system that even a moron could use, and only morons will
use it" // (q)
I'm absof#@...glutely sure there are no morons among our users,
so I know we don't need that - simply making the Owl a bit more
convenient for our neophytes would be quite enough (thus making
it more usable, as the usability is a sum of functionality and
convenience).
> However, if you want to play with matches it's you right :).
Personally I don't see any much difference between writing to the
sector 0 of the block device or to any other sector...
> It should be great to have such a smooth experience :). In my
> humble 15 years of systems administration I stumbled upon a dozen
> situations when LILO was broken in non-deterministic ways or had
> bugs that were not compatible with the environment.
Been there, seen those. Most of they were as simple as guessing
whether to use lba32 or linear mode.
> In any way, I see no point of discussing personal preferences
> here. The topic I raised was about the general direction we want
> to move to.
I see several directions we definitely don't want to move to, and
turning the system into a bloatware is at the top of that list.
>>> Anyway, this is irrelevant to the discussion.
>> This is relevant, as the situatioin with systemd is generally
>> the same, only it makes a lot more troubles.
> I'm currently managing 100+ CentOS 7 VMs with systemd and see no
> troubles or anything like that. So, it's a matter of perspective
> :).
Let me guess: those VMs are VDSes, not VPSes?
>>> we claim to be RH compatible, but our compatibility is lacking
>>> and behind like 8 years or so;
>> So don't claim this any longer, that's all.
> If we don't and if we do not provide compatibility, we are as
> good as dead. Our packages repository is way too small and the
> ability to "import" packages from a bigger distribution as easy
> as possible is the lifeline our distribution requires.
In general, `rpmbuild --rebuild thatpackage.src.rpm` performs that
"import" just fine. Of course, there are some proprietary software
out there, but... everything I've ever seen worked just fine.
> Since then things moved forward in other distros a lot, so yes,
> we can't install anything from recent releases of CentOS and/or FC.
Actually, we don't need to do that: we can either rebuild the RPM
package or set up that CentOS in a VPS.
> There is also the enterprise market and applications designed for
> RHEL. This is the part we are starting to lose (the commercial,
> binary-only packages start to move to RHEL 6/7). As an example,
> about 6 years ago I was able to install Plesk on Owl (I believe
> I documented it here at the time) and it was not hard, no it
> would be.
I guess the upgrade of glibc+openssh would solve this problem.
>>> it would be great to use Owl as a server VM distro on cloud
>>> providers, but we don't have Xen support and DHCP client out
>>> of the box, so most popular Clouds like AWS and RackSpace are
>>> not available to us out of the box;
>> So add them as packages, wy not? And what does all this have to
>> do with systemd?
> It's quite simple - there is a trend with the major distributions
Several years ago I've promised I wouldn't write to the lists being
drunk... Now, being sober, I'd say exactly the same thing: f#@k the
trends. Especially that stupid as udev, systemd and other $#it.
For now, I'm using CONFIG_DEVTMPFS=y and CONFIG_DEVTMPFS_MOUNT=y
- that required adding just a single `mkdir -pm755 /dev/pts` line
to our /etc/rc.d/rc.sysinit; also, to avoid ifconfig-inducted
bugs in the network initialization, I've tried to rewrite it to
use /sbin/ip - now that works for me and (hopefully) those 10 (or
so) people who've downloaded the ${subj}.
> I can accept an opinion that systemd is "evil" and that Owl is not
> going to use it, however, whoever pushes it should also contribute
> man power to keep Owl floating against the trend.
I've done that for the ${subj} now and it works for me.
> It's not "everything or nothing". The core values of Owl is that
> we keep to the principle of the least privilege (we are one of
> very few distros which does not have SUID binaries),
Yes, and that's the most significant point.
> we also put a lot of thought into the default configurations,
> do audits and fix insecurities other distros do not care about
> (e.g. insecure use of /tmp, etc.).
Alas, now that's doubtful: some of our default configurations are
inconvenient, which means unusable, which means insecure.
> However, somethings should be the same architecturally otherwise
> we are risking to be alone and incompatible. This is not an issue
> if you have enough funds and fully paid staff to do that, but we
> have neither, so we need to compromise.
JFYI: since 2000, I've got not even a single penny of any and all
Openwall fundings, but that didn't prevent me from:
1. using the Owl in almost all of my projects;
2. building additional packages for it;
3. attempting to make these packages both secure and usable;
4. distributing _everything_ I've produced during abovementioned
activities.
> There are many features systemd provides which were long time
> waited (e.g. resource limiting using cgroups, etc.) -- yes,
> the implementation is imperfect, but...
While it's imperfect, there's no place in the production area
for it.
> The modern world systems administration is no longer just about
> tinkering on servers in command-line, but deploying tens of VMs
> using configuration management, CI (e.g. Jenkins), etc. and Owl
> is simply falling behind.
Been there, seen those... alas, all that "configuration management"
ends up with either some primitive scripting or, in the worst case,
mousing the web-interface.
Having the Perl with the Socket module I don't need that, even for
all my (managed by me) over 100 physical servers with several VPSes
and VDSes running on them.
> Owl is a server distribution, so is our market. Windows' market
> share in the server segment is below 40%, so no majority here.
> Having GUI (e.g. X Window System) is out of scope and goals of
> Owl, yet it should be possible to install it from a compatible
> distribution (e.g. FC or CentOS), and this _was_ working many
> years ago and was used by us.
A year ago I've build X for Owl... however, there were not ordinary
PCs, but special devices.
> For the last 2 years the only systems I was running Owl were my
> personal ones since I believe that to contribute to something you
> should use it yourself first. I'm slowly starting to get tired and
> quite frustrated on the amount of time I spend to keep my systems
> up to date, to make them suitable to run services I want to run,
> etc. I have more than a hundred packages I'm maintaining and it
> takes significant amount of my time to update them and to keep
> up with corresponding upstreams.
1. Make a list of these packages
2. Sort it alphabetically
3. Look at it
4. Find the packages you would like be delegated to someone
5. Post the resulting list to -dev@
This would be much more productive.
--
Alexey V. Vissarionov aka Gremlin from Kremlin <gremlin ПРИ gremlin ТЧК ru>
GPG: 8832FE9FA791F7968AC96E4E909DAC45EF3B1FA8 @ hkp://keys.gnupg.net
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
