Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
20.02.2014 09:24, Canek Peláez Valdés пишет: [ snip ] but I do not see the point, beyond as a nice gimmick. Well, I *do* see a point. Many points, actually. You want the logs for SSH, from February 12 to February 15? Done: journalctl --since=2014-02-12 --until=2014-02-15 -u sshd.service No grep. No cat. No hunting logrotated logs (the journal will rotate automatically its logs, and will search on all logs available). You can have second-precision intervals. Also, the binary format that the journal uses is indexed (hence the binary part); therefore, the search is O(log n), no O(n). With a log with a million entries, that's about 20 steps. Perhaps it's just a gimmick to you. For me is a really usefull Clearly, it's reinventing a wheel. All that indexing stuff and O(log(n)) if really needed is easily achieved with databases. Not using cat and grep is not something one'd boast; rather, again, a waste of resources to recreate already existing tools. BTW, I wonder if anyone does really have logs with millions of lines in one single file, not split into files by date, service etc, so that the whole O(n) issue is moot. Well, maybe it'd be nice to have a collection of log management tools all-in-one but beyond that I don't see any advantages of systemd-journald. Its raison d'être is the new features it brings. I didn't notice any new features. It's not features that are new, but just a new implementation of old features in a more obtrusive way IMO. Additionally, the use of tail -f and grep allows me to check the logs real-time for debugging purposes. journalctl -f Checks the logs in real time. Again, [1]. Again, a brand new Wheel(c) systemctl status apache2.service (see [2]) will print the status of the Apache web server, and also the last lines from the logs. You can control how many lines. You can check also with the journal, as I showed up. I believe it would be a 5-minutes job to add the capability of printing last N log entries for a service to `rc-service status`. Using cat, grep and the like. Not reinventing wheels. Not spending super-talented super-highly paid developers' time on doing tasks one had done about 30 years ago. I believe, not having this option is due to its simple uselessness. This way I really wonder if at some point the super talented systemd programmers decide that all shell tools are obsolete and every program should know how to index or filter or tail its output in its own, though, open, binary format. I can't get rid of the idea that systemd uses the MS Windows approach whatever you say about its open source. -- Regards, Yuri K. Shatroff
Re: [gentoo-user] Fwd: How about the gentoo server or cluster in production environment?
On 02/20/2014 12:53 AM, Facundo Curti
wrote:
I think a "more stable" distro is better for production.
My choice is debian. I think you cant find nothing more
stable that debian...
Gentoo makes the best server os because it's a custom
built os where the admin knows each and every aspect of the
os.
This is true, but gentoo is a little unstable to use on
production. The system must be on 365 days/year. ¿and when you
need to update the system? This will use all the processor and
the system will be overloaded. This means users can't use the
system when this is updating...
the advantage of clustering servers though is you can take one out
and update it. if you use a distributed compliation [1] and tell
portage to keep the binaries [2] you can take a few out and do them
together, then the remainder do not require compilation as the
compile has been done.
I think the best for a server is debian. I didn't try red
hat but I see this like a commercial distro :/ Any way, red
hat is very used as server. And if you choice to pay, you will
have official support (Other wise, you are alone :/)
many of the cluster tools and services are actually written by
redhat so there is no surprise that there is much better
integration.
however i would much rather put gentoo in a public facing domain
where you need the latest security patches always.
getting clustering to work with gentoo can be a bit of a pain if you
are just feeling your way
the big question really is what is the purpose of your cluster ?
shared database load?
load balanced web servers?
distributed file system?
distributed multi system multi cpu calculations?
distributed fast memory cache ?
each thing has a different set of tools and management thereof.
P.D: I'm sorry if my english is not perfect, i
speak spanish
2014-02-19 21:36 GMT-03:00 Franklin
Wang touch2...@gmail.com:
Maybe it's
intresting, although I prefer to use red hat, suse or
ubuntu in datacenter as Google. Slackware servers're not
very poppular here
On 2014年02月20日 08:14, Nilesh Govindrajan wrote:
On 20 Feb 2014 05:12, "Franklin Wang"
touch2...@gmail.com
wrote:
and what about slackware for server?
Original Message
Subject:
How about the gentoo server or cluster in
production environment?
Date:
Fri, 29 Nov 2013 09:41:28 +0800
From:
Franklin Wang touch2...@gmail.com
To:
gentoo-ser...@lists.gentoo.org,
gentoo-clus...@lists.gentoo.org
Hi all,
I'm not familiar with gentoo server and
cluster. So could you tell me
the experience about them? Thanks.
Franklin Wang
Gentoo makes the best server os because
it's a custom built os where the admin knows each
and every aspect of the os. Security wise, there
are no unwanted or unused stuff, so lesser bugs to
deal with.
Clustering, well, you can do that using
glusterfs
--
skype:touch21st, Gtalk:touch21st, Yahoo/MSN:franklinwan...@yahoo.com,
Xing/Linkedin:Franklin Wang
[1] https://wiki.gentoo.org/wiki/Distcc
[2]
http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2chap=3#doc_chap4
[gentoo-user] Re: Fwd:How about the gentoo server or cluster in production environment?
The 20/02/14, Nilesh Govindrajan wrote: Gentoo makes the best server os because it's a custom built os where the admin knows each and every aspect of the os. Security wise, there are no unwanted or unused stuff, so lesser bugs to deal with. While I agree with the less code is less bug argument, I disagree with your point. Tuning softwares mean that the binaries compiled on a machine are less used in the wild (other Gentoo systems have other hardware, enabled use flags, etc). Hence, the binaries executed on you local server are likely much less tested by others. So, we can't say what is the true impact of use flags on security or stability compared to any widely-used pre-compiled distribution. -- Nicolas Sebrecht
[gentoo-user] Re: Debian just voted in systemd for default init system in jessie
The 20/02/14, Yuri K. Shatroff wrote: (see [2]) will print the status of the Apache web server, and also the last lines from the logs. You can control how many lines. You can check also with the journal, as I showed up. I believe it would be a 5-minutes job to add the capability of printing last N log entries for a service to `rc-service status`. Using cat, grep If I understand you correctly, what you're proposing is an analyzing tool which works after-the-facts. I mean extracting the per-daemon logs from a global log archive whereas systemd works the opposite way, AFAIU. You solution requires per-daemon extraction rules and have to be maintained over time. So, postponed to errors. Definetly not a 5-minutes job. -- Nicolas Sebrecht
Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie
20.02.2014 15:33, Nicolas Sebrecht пишет:
The 20/02/14, Yuri K. Shatroff wrote:
(see [2]) will print the status of the Apache web server, and also the
last lines from the logs. You can control how many lines. You can
check also with the journal, as I showed up.
I believe it would be a 5-minutes job to add the capability of printing
last N log entries for a service to `rc-service status`. Using cat, grep
If I understand you correctly, what you're proposing is an analyzing
tool which works after-the-facts.
I wasn't proposing anything. I was just supposing.
I mean extracting the per-daemon logs
from a global log archive whereas systemd works the opposite way, AFAIU.
What is a 'global log archive'? Do you mean a single file where all logs
go? AFAIK you can set up syslog to log all messages into one file as
well as per-service files. So the deal is just to extract configuration
from syslog. Of course, if the services are using it, not keeping their
own logs as is usually the case of apache. As a multiuser (multi-vhost)
webserver admin I have to set up apache to log into users' home
directories, so I even don't know how many user logs there really are.
And I don't need to, because I've got my own global log. But a user is
definitely more familiar with a text file he/she can download via FTP,
than with a journalctl wrapper which he has to know how to use (and also
be granted SSH access to use), at the least which parameters to specify,
if at all usable in such setups.
You solution requires per-daemon extraction rules and have to be
maintained over time. So, postponed to errors.
I don't need such 'solutions' to non-existent problems. But if there
were a *real* necessity to pretty-print a log's tail in service status,
I think it would have been a matter of a proper setup (i.e. the service
using syslog, hence a defined log format) and not a heck more complicated.
Definetly not a 5-minutes job.
5 minutes is even too much to type sort of
tail -${LINES} ${SERVICE}.log
if you know where to look up LINES and SERVICE.
--
Regards,
Yuri K. Shatroff
Re: [gentoo-user] Fwd: How about the gentoo server or cluster in production environment?
On 2014-02-19 7:53 PM, Facundo Curti facu.cu...@gmail.com wrote: This is true, but gentoo is a little unstable to use on production. The system must be on 365 days/year. ¿and when you need to update the system? This will use all the processor and the system will be overloaded. This means users can't use the system when this is updating... That is such total FUD I just can't even say anything else about it without using some unsavory words. I had an old underpowered server (only 2GB of RAM) that supported about 100 users using IMAP to access their huge maildir mailstores (some users have 20+GB of mail). I kept the thing updated on a regular basis, and the only time it ever went down was to reboot after a kernel upgrade. Updates to all of the other software - postfix and courier-imap (now dovecot) were always done on the live system, and interruption in service was only momentary when I restarted the services after the updates. So please... there may be some legitimate philosophical or other reasons (PHB?) not to use gentoo, but what you said ain't one of them.
Re: [gentoo-user] Fwd: How about the gentoo server or cluster in production environment?
On 2014-02-20 7:04 AM, Tanstaafl tansta...@libertytrek.org wrote: On 2014-02-19 7:53 PM, Facundo Curti facu.cu...@gmail.com wrote: This is true, but gentoo is a little unstable to use on production. The system must be on 365 days/year. ¿and when you need to update the system? This will use all the processor and the system will be overloaded. This means users can't use the system when this is updating... That is such total FUD I just can't even say anything else about it without using some unsavory words. I had an old underpowered server (only 2GB of RAM) that supported about 100 users using IMAP to access their huge maildir mailstores (some users have 20+GB of mail). I kept the thing updated on a regular basis, and the only time it ever went down was to reboot after a kernel upgrade. And I neglected a main factor - this server was running and serving this many users and being updated simultaneously like this for about 9 YEARS. I only just recently (in the last couple of months) replaced it with a shiny new gentoo VM running on my shiny new vmWare host, and I only did that because I wanted to enable dovecots on disk indexes but couldn't do that without adding more RAM and more disk space to the old box, and since I had a shiny new vmWare host, it only made sense to ditch the old box.
[gentoo-user] emerge all packages which depend on P : how to
Hi, I have a very simple question. How to emerge (update) all packages which depend on some given package P. I've tried emerge -uv1 `equery -q d P` or emerge -uv1 `qdepends -q -Q P` but both commands (equery and qdepends) generate a list with the version attached like app-editors/kile-2.1.3 which emerge doesn't like (unless there is an '= in front of each name) Is there an easy way to do so without resorting to shell/python scripting? Many thanks for a hint, Helmut
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On 2014-02-20 12:43 AM, Canek Peláez Valdés can...@gmail.com wrote: On Wed, Feb 19, 2014 at 6:38 AM, Tanstaafltansta...@libertytrek.org wrote: On 2014-02-19 2:04 AM, Daniel Campbellli...@sporkbox.us wrote: For such a profile to be legitimate, systemd would have to be chosen as the default. Ridiculous. Forget about Canek's rant... This is about *choice*. Also, I would argue the *opposite of what Canek is saying in this last rant... Tanstaafl, can we please not use terms like rants? I'm just giving my opinion, trying to be respectful and civil to the others participants in this thread. I would appreciate if you do the same to me. Sorry, Canek, no offense was intended, but if you go back and re-read your 'extremely overly enthusiastic' post (this plus the content is why I referred to it as a 'rant'), while I agree with most everything you said, your primary point - that it should be the people who *don't* want systemd doing all of the work - was backwards, and that was what I wanted to point out. So, please, don't take it as an insult. In fact you have done a very good job of patiently spelling out the advantages of systemd, to the point I'm no longer afraid of it taking over and devouring the linux world. That said, in reality, there is (or should be) nothing inherently insulting about a claim that something you (or anyone) says was a 'rant'. Pretty much everyone I know who has strong opinions on things like this rants all the time. Sometimes those rants have more value/substance than others. A good rant will provide lots of substantive supporting documentation backing up the claims in the rant. A bad rant just makes a bunch of baseless claims and/or personal attacks. Bottom line: since Gentoo's default and primary init system is (and hopefully will be for a very long time) OpenRC, it is on the systemd folks to do the work to get systemd fully supported.
Re: [gentoo-user] emerge all packages which depend on P : how to
2014-02-20 13:38 GMT+01:00 Helmut Jarausch jarau...@igpm.rwth-aachen.de: Hi, I have a very simple question. How to emerge (update) all packages which depend on some given package P. I've tried emerge -uv1 `equery -q d P` or emerge -uv1 `qdepends -q -Q P` but both commands (equery and qdepends) generate a list with the version attached like app-editors/kile-2.1.3 which emerge doesn't like (unless there is an '= in front of each name) Is there an easy way to do so without resorting to shell/python scripting? Many thanks for a hint, Helmut Hi, I just had a look on eix and figured out that eix --deps -# -I P lists all packages in short for that are installed and have P in their dependency variables plus the package itself. Hope to help -- Mit freundlichen Grüßen / Best regards Randolph Maaßen
[gentoo-user] Re: emerge all packages which depend on P : how to
On Thu, 20 Feb 2014 13:38:06 +0100, Helmut Jarausch jarau...@igpm.rwth-aachen.de wrote: Hi, I have a very simple question. How to emerge (update) all packages which depend on some given package P. I've tried emerge -uv1 `equery -q d P` or emerge -uv1 `qdepends -q -Q P` but both commands (equery and qdepends) generate a list with the version attached like app-editors/kile-2.1.3 which emerge doesn't like (unless there is an '= in front of each name) Is there an easy way to do so without resorting to shell/python scripting? Many thanks for a hint, Helmut How about one of these? emerge -1 $(qdepends -N -C -Q P) emerge -1 $(qdepends -C -Q P | sed 's/^/=/') -- eroen signature.asc Description: PGP signature
Re: [gentoo-user] emerge all packages which depend on P : how to
On Thu, 20 Feb 2014 13:38:06 +0100, Helmut Jarausch wrote: I've tried emerge -uv1 `equery -q d P` or emerge -uv1 `qdepends -q -Q P` but both commands (equery and qdepends) generate a list with the version attached like app-editors/kile-2.1.3 which emerge doesn't like (unless there is an '= in front of each name) Is there an easy way to do so without resorting to shell/python scripting? Stripping the version, which you can do with qatom, is not a good idea because it will only reinstall the newest version of any slotted packages. Best to use sed to prefix each atom with = emerge -1a $(qdepends -qQ P | sed 's/^/=/') Also, the use of -u in your examples means currently installed packages will not be re-emerged, unless a newer version is available. -- Neil Bothwick Monday is the root of all evil! signature.asc Description: PGP signature
Re: [gentoo-user] Fwd: How about the gentoo server or cluster in production environment?
Hi, On Thu, 20 Feb 2014 07:40:59 +0800 Franklin Wang wrote: I'm not familiar with gentoo server and cluster. So could you tell me the experience about them? Thanks. We have successful experience with Gentoo on both production servers (someone call this area enterprise, though I dislike such name) and HPC setups. In short, Procs: - fine-tuned setups; - really large choice of components; - high-performance setups (especially rocks for HPC); - reduced attack surface; - nontrivial attack surface; - large system updates easy (comparted to e.g. RHEL4 - RHEL5 migration); - easier to add and maintain out-of-tree software. Cons: - much longer time for initial setup; - harder to apply routine updates; - poorly suitable for tasks like: create me this new service ASAP (for which you don't have prepared images), preferably yesterday. Other notes: - requires more qualified personnel to maintain. Best regards, Andrew Savchenko pgpkbel_Wkp06.pgp Description: PGP signature
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On 20/02/2014 11:16, Yuri K. Shatroff wrote: 20.02.2014 09:24, Canek Peláez Valdés пишет: [ snip ] but I do not see the point, beyond as a nice gimmick. Well, I *do* see a point. Many points, actually. You want the logs for SSH, from February 12 to February 15? Done: journalctl --since=2014-02-12 --until=2014-02-15 -u sshd.service No grep. No cat. No hunting logrotated logs (the journal will rotate automatically its logs, and will search on all logs available). You can have second-precision intervals. Also, the binary format that the journal uses is indexed (hence the binary part); therefore, the search is O(log n), no O(n). With a log with a million entries, that's about 20 steps. Perhaps it's just a gimmick to you. For me is a really usefull Clearly, it's reinventing a wheel. All that indexing stuff and O(log(n)) if really needed is easily achieved with databases. Not using cat and grep is not something one'd boast; rather, again, a waste of resources to recreate already existing tools. BTW, I wonder if anyone does really have logs with millions of lines in one single file, not split into files by date, service etc, so that the whole O(n) issue is moot. I have logs like that. It's not an uncommon scenario. Well, maybe it'd be nice to have a collection of log management tools all-in-one but beyond that I don't see any advantages of systemd-journald. The immediate feature-add that syslog needs is arbitrary facilities, not the 16 fixed ones in syslog() system call. Its raison d'être is the new features it brings. I didn't notice any new features. It's not features that are new, but just a new implementation of old features in a more obtrusive way IMO. Additionally, the use of tail -f and grep allows me to check the logs real-time for debugging purposes. journalctl -f Checks the logs in real time. Again, [1]. Again, a brand new Wheel(c) systemctl status apache2.service (see [2]) will print the status of the Apache web server, and also the last lines from the logs. You can control how many lines. You can check also with the journal, as I showed up. I believe it would be a 5-minutes job to add the capability of printing last N log entries for a service to `rc-service status`. Using cat, grep and the like. No, that will not work easily for all definitions of easily. rc-something has zero control over where the logs go and no standard method to provide hints to the logger. Gentoo ships syslog* configs that basically stick everything in messages, where grepping them out is a PITA. I usually rewrite that config more to my taste and needs and rc-service cannot know what I did. So the idea fails at step 1 as the code does not know where the logs are. Not reinventing wheels. Not spending super-talented super-highly paid developers' time on doing tasks one had done about 30 years ago. I believe, not having this option is due to its simple uselessness. 30 years ago we had isolated stand-alone machines without nothing like the logging needs we have today. Whilst I agree with you that systemd's logging tools may not be the solution, I can assure you (as someone who has to deal with this shit) that syslogging in the modern world is a mess. Try this: Decide you cannot afford Splunk, so do it yourself. Now get your Apache access logs into the same searchable database your other stuff is in, and do it in such a way that you can SELECT what you want out in obvious ways. Repeat for every other app you have that logs stuff. Remember to find the really important logs which are usually sitting in /opt/ and produced by Log4Perl or something equally abominable. This way I really wonder if at some point the super talented systemd programmers decide that all shell tools are obsolete and every program should know how to index or filter or tail its output in its own, though, open, binary format. I can't get rid of the idea that systemd uses the MS Windows approach whatever you say about its open source. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie
On 20/02/2014 13:53, Yuri K. Shatroff wrote:
I don't need such 'solutions' to non-existent problems. But if there
were a *real* necessity to pretty-print a log's tail in service status,
I think it would have been a matter of a proper setup (i.e. the service
using syslog, hence a defined log format) and not a heck more complicated.
Definetly not a 5-minutes job.
5 minutes is even too much to type sort of
tail -${LINES} ${SERVICE}.log
if you know where to look up LINES and SERVICE.
You've never actually tried this, right?
Your idea instantly fails as the rc-service author has no idea of what
you defined ${SERVICE} to be and no way to determine what it is now.
How are you going to deal with the situation with a big busy daemon that
immediately starts serving requests when started (i.e. with very little
delay)?
By the time grep, sed, awk and friends have gotten around to making
their way through a log file of varying size, the entries that apply to
restart can easy be many hundreds of log lines prior.
I have done this, and it does not work. I got a result and it's
relaible, but you don't want to know what it took. It's also highly
customized and useless to anything other than my highly customized setup.
--
Alan McKinnon
alan.mckin...@gmail.com
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Thu, Feb 20, 2014 at 6:53 AM, Tanstaafl tansta...@libertytrek.org wrote: On 2014-02-20 12:43 AM, Canek Peláez Valdés can...@gmail.com wrote: On Wed, Feb 19, 2014 at 6:38 AM, Tanstaafltansta...@libertytrek.org wrote: On 2014-02-19 2:04 AM, Daniel Campbellli...@sporkbox.us wrote: For such a profile to be legitimate, systemd would have to be chosen as the default. Ridiculous. Forget about Canek's rant... This is about *choice*. Also, I would argue the *opposite of what Canek is saying in this last rant... Tanstaafl, can we please not use terms like rants? I'm just giving my opinion, trying to be respectful and civil to the others participants in this thread. I would appreciate if you do the same to me. Sorry, Canek, no offense was intended, but if you go back and re-read your 'extremely overly enthusiastic' post (this plus the content is why I referred to it as a 'rant'), Thanks for the explanation. while I agree with most everything you said, your primary point - that it should be the people who *don't* want systemd doing all of the work - was backwards, and that was what I wanted to point out. I still believe that a non-systemd profile should be done by the people not wanting to use systemd. But since I now support the systemd profile (since it's trivial) the point is moot. So, please, don't take it as an insult. In fact you have done a very good job of patiently spelling out the advantages of systemd, to the point I'm no longer afraid of it taking over and devouring the linux world. Thanks. That said, in reality, there is (or should be) nothing inherently insulting about a claim that something you (or anyone) says was a 'rant'. Pretty much everyone I know who has strong opinions on things like this rants all the time. Sometimes those rants have more value/substance than others. A good rant will provide lots of substantive supporting documentation backing up the claims in the rant. A bad rant just makes a bunch of baseless claims and/or personal attacks. I don't think I was shouting (which I believe is part of the rant definition); but whatever, I now understand you didn't mean any harm and I appreciate it. Bottom line: since Gentoo's default and primary init system is (and hopefully will be for a very long time) OpenRC, it is on the systemd folks to do the work to get systemd fully supported. Which has been the case up until now. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Thu, Feb 20, 2014 at 3:16 AM, Yuri K. Shatroff yks-...@yandex.ru wrote: 20.02.2014 09:24, Canek Peláez Valdés пишет: [ snip ] but I do not see the point, beyond as a nice gimmick. Well, I *do* see a point. Many points, actually. You want the logs for SSH, from February 12 to February 15? Done: journalctl --since=2014-02-12 --until=2014-02-15 -u sshd.service No grep. No cat. No hunting logrotated logs (the journal will rotate automatically its logs, and will search on all logs available). You can have second-precision intervals. Also, the binary format that the journal uses is indexed (hence the binary part); therefore, the search is O(log n), no O(n). With a log with a million entries, that's about 20 steps. Perhaps it's just a gimmick to you. For me is a really usefull Clearly, it's reinventing a wheel. Where I come from, doing something that takes O(n) in O(log n) is nor reinventing the wheel, but, OK, see it that way if you want to. Simply don't use it. All that indexing stuff and O(log(n)) if really needed is easily achieved with databases. The journal is a specialized database for logs. Not using cat and grep is not something one'd boast; rather, again, a waste of resources to recreate already existing tools. Are those *your* resources? If not, what's the problem? BTW, I wonder if anyone does really have logs with millions of lines in one single file, not split into files by date, service etc, so that the whole O(n) issue is moot. Oh boy, you haven't worked much in enterprise, right? Also, even if *one* machine doesn't have logs with a million lines (which I've seen it, in real life, in *production*, but whatever), the journal can send (automatically, of course, if so configured) logs to a central server. So you can coalesce the logs from *all* your network in a single place, and with the journal you can merge them when doing queries. Again, Everything in O(log n). Si right now I have a little server with logs of ~75,000 lines. If I had 20 (nothing weird in enterprise, may would call that a really small operation), that would be logs of 1,500,000 lines. With the journal, you could check *all* your servers with a single command, and all the queries could be done in O(log n). So, yeah, moot. Well, maybe it'd be nice to have a collection of log management tools all-in-one but beyond that I don't see any advantages of systemd-journald. Then, again, don't use it. Its raison d'être is the new features it brings. I didn't notice any new features. It's not features that are new, but just a new implementation of old features in a more obtrusive way IMO. Again, O(n) vs. O(log n). Coalescing logs from different machines. A single powerful tool with well define semantics to query the logs. So, yeah, no new features. Additionally, the use of tail -f and grep allows me to check the logs real-time for debugging purposes. journalctl -f Checks the logs in real time. Again, [1]. Again, a brand new Wheel(c) I never said that was a new feature. Roeleveld said that he could use tail -f and grep, like that was not possible with the journal. I was proving him it could be done with the journal. systemctl status apache2.service (see [2]) will print the status of the Apache web server, and also the last lines from the logs. You can control how many lines. You can check also with the journal, as I showed up. I believe it would be a 5-minutes job to add the capability of printing last N log entries for a service to `rc-service status`. Using cat, grep and the like. Not reinventing wheels. Not spending super-talented super-highly paid developers' time on doing tasks one had done about 30 years ago. I believe, not having this option is due to its simple uselessness. Others have chimed in on the infeasibility of this claim. However, if you don't want to use the journal, and can emulate everything it does in 5 minutes, then don't use the journal and write your little shell scripts in 5 minutes. I'd rather see cats with Wolverine claws in YouTube with those 5 minutes, and let the journal do the thing. But that's me. This way I really wonder if at some point the super talented systemd programmers decide that all shell tools are obsolete and every program should know how to index or filter or tail its output in its own, though, open, binary format. I can't get rid of the idea that systemd uses the MS Windows approach whatever you say about its open source. Again, the journal can export an output (and really fast, since it has everything indexed) that is 100% identical to the output of any other logger. And you can use on it shell, grep and sed to your heart's desire. But if you don't want to, then don't use the journal. Nobody is forcing it on you. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Re: Fwd:How about the gentoo server or cluster in production environment?
On Thu, 20 Feb 2014 11:29:52 +0100 Nicolas Sebrecht wrote: The 20/02/14, Nilesh Govindrajan wrote: Gentoo makes the best server os because it's a custom built os where the admin knows each and every aspect of the os. Security wise, there are no unwanted or unused stuff, so lesser bugs to deal with. While I agree with the less code is less bug argument, I disagree with your point. Tuning softwares mean that the binaries compiled on a machine are less used in the wild (other Gentoo systems have other hardware, enabled use flags, etc). Hence, the binaries executed on you local server are likely much less tested by others. And this point is one of the highest security benefits in real world: one have non-standard binaries, not available in the wild. Most exploits will fail on such binaries even if vulnerability is still there. This will cut-off most off automatic botnet attacks even without additional security measures like hardened setup, PaX or GRSecurity (yeah, I never trusted SELinux because of its main author: sane agency will never release a security tool which can be a hinder to this agency). Of course, if system is specifically targeted by qualified professionals, this will only hinder their approach, but binary based distributions will not provide any advantage here either. Best regards, Andrew Savchenko pgpdyWR4NlZ8L.pgp Description: PGP signature
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On 2014-02-20 10:55 AM, Canek Peláez Valdés can...@gmail.com wrote: On Thu, Feb 20, 2014 at 6:53 AM, Tanstaafl tansta...@libertytrek.org wrote: while I agree with most everything you said, your primary point - that it should be the people who *don't* want systemd doing all of the work - was backwards, and that was what I wanted to point out. I still believe that a non-systemd profile should be done by the people not wanting to use systemd. But since I now support the systemd profile (since it's trivial) the point is moot. snip Bottom line: since Gentoo's default and primary init system is (and hopefully will be for a very long time) OpenRC, it is on the systemd folks to do the work to get systemd fully supported. Which has been the case up until now. As you have freely admitted that OpenRC being the default init system for gentoo is unlikely to change anytime soon, I'm at a loss as to how you can justify your first comment above? Your comment would only make sense if systemd was made the default init system.
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Thu, Feb 20, 2014 at 12:18 PM, Tanstaafl tansta...@libertytrek.org wrote: On 2014-02-20 10:55 AM, Canek Peláez Valdés can...@gmail.com wrote: On Thu, Feb 20, 2014 at 6:53 AM, Tanstaafl tansta...@libertytrek.org wrote: while I agree with most everything you said, your primary point - that it should be the people who *don't* want systemd doing all of the work - was backwards, and that was what I wanted to point out. I still believe that a non-systemd profile should be done by the people not wanting to use systemd. But since I now support the systemd profile (since it's trivial) the point is moot. snip Bottom line: since Gentoo's default and primary init system is (and hopefully will be for a very long time) OpenRC, it is on the systemd folks to do the work to get systemd fully supported. Which has been the case up until now. As you have freely admitted that OpenRC being the default init system for gentoo is unlikely to change anytime soon, I'm at a loss as to how you can justify your first comment above? Your comment would only make sense if systemd was made the default init system. OK, I think I get the misunderstanding. This is how I saw the discussion: 1. Some people started to say that systemd should go on its own profile. The people saying that DID NOT wanted to use systemd. 2. I thought that the people using systemd were not interested in making a systemd profile (I was wrong, the profile basically already exists). 3. Since you cannot FORCE no one to work on something, then the burden of work of this systemd profile would have landed on the people NOT WANTING to use systemd. To me, this does not make sense. 4. When someone (don't remember whom) proposed a systemd-sucks profile, I thought that was perfect, because the burden of work then would have landed on the people that want this profile. I even volunteered to help. 5. The moment I saw that the profile is already done, I changed my mind; the people using systemd ALREADY did the work (which seems to be trivial, BTW; I didn't knew that either), therefore no one is trying forcing anyone to do work, then a systemd profile is fine (since it's already done). This is orthogonal to which init system is the default, I think. I was just arguing that if a group A of people want a profile X, that group A of people must do the work to get said profile X working. In the case of systemd, that means *using* systemd, so it made no sense to me that the group A did the work, when they *do not* want to use systemd. Once again, all of this is made moot by the fact that the systemd profile is basically available now. But that does not change my point that if someone wants a X profile, then the burden of work must fall on that someone. Clear now? Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Fwd: How about the gentoo server or cluster in production environment?
Original Message Subject: How about the gentoo server or cluster in production environment? Date: Fri, 29 Nov 2013 09:41:28 +0800 From: Franklin Wang touch2...@gmail.com To: gentoo-ser...@lists.gentoo.org, gentoo-clus...@lists.gentoo.org Hi all, I'm not familiar with gentoo server and cluster. So could you tell me the experience about them? Thanks. There are some quite decent clusters running Gentoo. See the homepage of the cluster team, https://www.gentoo.org/proj/en/cluster/ and also the link there Clusters running Gentoo. -- Andreas K. Huettel Gentoo Linux developer kde, council
[gentoo-user] Re: Fwd:How about the gentoo server or cluster in production environment?
On Thu, Feb 20, 2014 at 08:52:07PM +0400, Andrew Savchenko wrote: And this point is one of the highest security benefits in real world: one have non-standard binaries, not available in the wild. Most exploits will fail on such binaries even if vulnerability is still there. While excluding few security issues by compiling less code is possible, believing that non-standard binaries (in the sense of compiled for with local compilation flags) gives more security is a dangerous dream. -- Nicolas Sebrecht
Re: [gentoo-user] Re: Fwd:How about the gentoo server or cluster in production environment?
On 20/02/2014 22:41, Nicolas Sebrecht wrote: On Thu, Feb 20, 2014 at 08:52:07PM +0400, Andrew Savchenko wrote: And this point is one of the highest security benefits in real world: one have non-standard binaries, not available in the wild. Most exploits will fail on such binaries even if vulnerability is still there. While excluding few security issues by compiling less code is possible, believing that non-standard binaries (in the sense of compiled for with local compilation flags) gives more security is a dangerous dream. +1 non-standard binaries is really just a special form of security by obscurity. Or alternatively a special form of no-one will eva figure out my l33t skillz! Mwahahaha! Which is a very poor stance to take. The total amount of code not compiled by setting some USE flags off is on the whole not likely to be very much, and hoping with finger crossed that the next weakness in a package will just happen to fall within a code path that got left out by USE flags is a fools dream. I'm glad you mentioned this Andrew, because the internets are full of stupid advice like this non-standard binary nonsense. Yes, the arguments at face value are difficult to refute with hard facts, but those that do not known it is stupid are easily led into a sense of false security, doesn't matter how many disclaimers are tagged on the end. I reckon it's the duty of all knowledgeable sysadmins to stamp out this crap HARD every time it raises it's head. To the user who brought it up - this might seem overly harsh but I've yet to find a better method that actually works and gets through to people. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Thu, Feb 20, 2014 at 2:06 PM, Tanstaafl tansta...@libertytrek.org wrote: On 2014-02-20 1:36 PM, Canek Peláez Valdés can...@gmail.com wrote: The moment I saw that the profile is already done, I changed my mind; the people using systemd ALREADY did the work (which seems to be trivial, BTW; I didn't knew that either), therefore no one is trying forcing anyone to do work, then a systemd profile is fine (since it's already done). Well, sort of... there are currently only two systemd profiles (gnome and kde). No, the link [1] that Andreas K. Huettel posted in [2] (which I believe you never saw) *IS* basically all you need for a systemd profile. It's, almost literally, *nothing*. Is someone wants to use systemd with any of the other predefined profiles, ie: default/linux/amd64/13.0 then their current choice is to change to systemd manually (which as you and others have pointed out doesn't seem to be that big a deal), or, if they wanted to make it easier for anyone/everyone else (which, I believe, as a systemd proponent, you would be in favor of) to choose systemd at install time, they could do the work of creating a new systemd version of each of the other profiles. Hmmm... Thinking about this more, since apparently using a separate profile may just be 'overkill', how about something simpler, like, for example, using eselect... Something like: # eselect init list Available init systems: [1] OpenRC * [2] systemd [3] runit (whatever choices are supported). Or am I just being ridiculous? No, yo are not; but the switching requires reemerging things because you need to set some USE flags and quit others. That's the difficult (which is not, really) part; if you set the USE flags yourself or via a profile, or an eselect module, I don't think the difference matters at all. This is orthogonal to which init system is the default, I think. No, actually, I think whatever is defined as the current default should dictate which group should be required to do the work. I think this is where we think differently (regarding this particular point). The work must be done by *whomever* wants to do the job. So if the systemd people want to do a profile that's fine (and this already happened); but if they don't want to, nobody can force them to do it (this is academic right now, since they already did the [pretty trivial] work). If the systemd people did not wanted to do the job, then, since you can't force them, the people *not* wanting systemd would be the ones required to do it. And that makes absolutely no sense. Again, this is all moot since the profile already exists. And even without a profile, the change is easy enough. I was just arguing that if a group A of people want a profile X, that group A of people must do the work to get said profile X working. In the case of systemd, that means *using* systemd, so it made no sense to me that the group A did the work, when they *do not* want to use systemd. ? If Group A wants to be able to easily use systemd in gentoo, then Group A people must get together and create systemd version of all of the profiles they want to be able to use systemd with... ie, if they want a hardened amd64 systemd profile, they would have to create one. That's the failing in your logic (IMO); if group A wants systemd, they already got it. No profile would make it easier (since reemerging stuff will still be necessary), so we don't really need it. Even so, such a profile (or candidate for a profile, if you desire to call it that way) already exists. But if nobody wants to do a systemd proper profile, that's fine, and nobody will force no one to write it. Once again, all of this is made moot by the fact that the systemd profile is basically available now. But that does not change my point that if someone wants a X profile, then the burden of work must fall on that someone. I agree... but since OpenRC is the default init system for gentoo, and certain people want to make it easier for people to install and/or switch to systemd in gentoo, then it is on *those* people to do the work. If someone willing and able wants to do the work, it will be done. If nobody wants to do the work, the work will not get done. Business as usual in Gentoo and Linux. I'm still not sure why we are still discussing this... ;) Just some different views on how the work gets done, I think. Maybe a language thing? Possibly. Regards. [1] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/profiles/targets/systemd/ [2] http://article.gmane.org/gmane.linux.gentoo.user/272668 -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
[gentoo-user] OT: bootable CD/DVD/USB that can boot any ISO images on the disk?
Hi all, Does anyone know of any software that can create a bootable CD/DVD or USB stick, that has a customizable menu that will let you boot pretty much any ISO file you copy to the disk and point to with the menu? It seems like I've seen something like this before, but all I can find are ones that only work with certain/particular pre-defined images.
Re: [gentoo-user] OT: bootable CD/DVD/USB that can boot any ISO images on the disk?
On 20 febbraio 2014 22:06:45 CET, Tanstaafl tansta...@libertytrek.org wrote: Hi all, Does anyone know of any software that can create a bootable CD/DVD or USB stick, that has a customizable menu that will let you boot pretty much any ISO file you copy to the disk and point to with the menu? Looks like Unetbootin is the piece of software you need: http://unetbootin.sourceforge.net/ -- Giuseppe pappi Pappalardo | www.giuseppepappalardo.eu | www.twitter.com/pappi_
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Thu, Feb 20, 2014 at 3:22 PM, Tanstaafl tansta...@libertytrek.org wrote: On 2014-02-20 4:04 PM, Canek Peláez Valdés can...@gmail.com wrote: No, actually, I think whatever is defined as the current default should dictate which group should be required to do the work. I think this is where we think differently (regarding this particular point). The work must be done by *whomever* wants to do the job. So if the systemd people want to do a profile that's fine (and this already happened); but if they don't want to, nobody can force them to do it (this is academic right now, since they already did the [pretty trivial] work). If the systemd people did not wanted to do the job, then, since you can't force them, the people *not* wanting systemd would be the ones required to do it. And that makes absolutely no sense. I think we agree, but you keep saying we don't... ;) The difference is, since OpenRC is the default, all of the existing profiles are, by definition, OpenRC based profiles. So, people who don't want systemd simply have to do... nothing! OK, I see your point. As I said before, it is people who want systemd who currently have to 'do something', and that is as it should be, unless/until the default of OpenRC is changed to systemd. Agreed. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] OT: bootable CD/DVD/USB that can boot any ISO images on the disk?
On Thu, 20 Feb 2014 16:06:45 -0500, Tanstaafl wrote: Does anyone know of any software that can create a bootable CD/DVD or USB stick, that has a customizable menu that will let you boot pretty much any ISO file you copy to the disk and point to with the menu? I tried something called MultiBootUSB, google for it, which did a fairly decent job. It seems like I've seen something like this before, but all I can find are ones that only work with certain/particular pre-defined images. That's because some ISO images are bootable like this and some are not, and the ones that are use various incompatible boot systems. I've just been trying to get an ISO of a Fedora-derived distro to boot like this, but they modified the initrd scripts for no apparent reason better than changing the names to look like theirs, and deleted the ISO booting options in the process. I ended up crating a custom initrd just to get back some of the functionality that had been there in the first place :( -- Neil Bothwick Growing old is mandatory; growing up is optional!! signature.asc Description: PGP signature
[gentoo-user] systemd and USE=static
I thought I'd have another look at systemd, so switched profiles, made sure I had all the kernel options needed and then did an emerge -uN world. It seems the systemd profile masks the static and static-libs USE flags, which are needed by crytsetup and lvm for my initramfs, which mounts / from a LUKS partition. Forcing an unmask of these flags in /etc/portage/profile did no good because when those packages are built with USE=static they require a virtual/udev with matching flags, which systemd cannot provide. Is there a way around this or have a I found a reason for not using systemd that doesn't involve name calling? :-O -- Neil Bothwick Genius is 99% inspiration and 2% arithmetic signature.asc Description: PGP signature
Re: [gentoo-user] flickering thunderbird and firefox
ons 2014-02-19 klockan 21:14 +0100 skrev Stefan G. Weichinger: Am 19.02.2014 20:02, schrieb Alan McKinnon: Yes, it can. But not in the obvious way. Video cards and GPUs are complex devices implementing numerous features. It is possible that your GPU/video card hardware is broken wrt one or a few of these features and Mozilla apps are the only ones you use that make use of these features. It's a bit of a perfect storm situation and frankly, software drivers are more likely to provoke it than broken hardware. I would keep the possibility in the back of my head to be checked way down the line of possibilities though. Meanwhile, if your hardware vendor provides a hardware diagnostics tool you could run it for fun and see what it says. Those tests are fairly rapid so you don't lose much by giving it a spin. I could boot from a live cd to cross check ... will try that. or you could do that ^^^ instead :-) I might do that, thanks. An ubuntu-live-cd showed no problems. Although for sure it was a different set of software ... other kernel, nvidia-drivers, gnome We'll see ... I have seen this flickering in gnome-terminal, in nxclient and also in the window title of chromium. I am using gentoo-sources-3.13.3, nvidia-drivers-334.16-r7 and chromium-33.0.1750.70. Both in gnome-terminal and in nxclient it looked like some kind of blink-attribute was used. ;) BR / P-E
Re: [gentoo-user] systemd and USE=static
On Thu, Feb 20, 2014 at 4:48 PM, Neil Bothwick n...@digimed.co.uk wrote: I thought I'd have another look at systemd, so switched profiles, made sure I had all the kernel options needed and then did an emerge -uN world. It seems the systemd profile masks the static and static-libs USE flags, which are needed by crytsetup and lvm for my initramfs, which mounts / from a LUKS partition. Forcing an unmask of these flags in /etc/portage/profile did no good because when those packages are built with USE=static they require a virtual/udev with matching flags, which systemd cannot provide. Is there a way around this or have a I found a reason for not using systemd that doesn't involve name calling? :-O I would recommend using an initramfs which includes the necessary shared libraries. I'm pretty sure dracut and genkernel-next support this. If you roll your own initramfs, this isn't terribly difficult either -- just use ldd to figure out which files you need, and copy them to /lib or /lib64 in the intiramfs image.
[gentoo-user] Re: systemd and USE=static
On Thu, 20 Feb 2014 21:48:01 +, Neil Bothwick n...@digimed.co.uk wrote: I thought I'd have another look at systemd, so switched profiles, made sure I had all the kernel options needed and then did an emerge -uN world. It seems the systemd profile masks the static and static-libs USE flags, which are needed by crytsetup and lvm for my initramfs, which mounts / from a LUKS partition. Forcing an unmask of these flags in /etc/portage/profile did no good because when those packages are built with USE=static they require a virtual/udev with matching flags, which systemd cannot provide. Is there a way around this or have a I found a reason for not using systemd that doesn't involve name calling? :-O You are right, systemd dropped support for static libudev (or any other library for that matter) in version 205.[1] If you want to use systemd provided libudev for lvm c. in an initramfs, you'll need to include the shared library and binaries linked to it. I believe both dracut and genkernel-next support shared libudev, while the current versions of genkernel do not (hence why genkernel is masked on the */systemd profiles). While I have limited experience with genkernel, dracut has dragged in all the shared libraries I have required of it. 1: http://cgit.freedesktop.org/systemd/systemd/commit/?id=5e63ce78b5018ba612e794a610a6f13c5eefade7 -- eroen signature.asc Description: PGP signature
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Thu, 20 Feb 2014 15:38:46 -0600 Canek Peláez Valdés can...@gmail.com wrote: On Thu, Feb 20, 2014 at 3:22 PM, Tanstaafl tansta...@libertytrek.org wrote: On 2014-02-20 4:04 PM, Canek Peláez Valdés can...@gmail.com wrote: No, actually, I think whatever is defined as the current default should dictate which group should be required to do the work. I think this is where we think differently (regarding this particular point). The work must be done by *whomever* wants to do the job. So if the systemd people want to do a profile that's fine (and this already happened); but if they don't want to, nobody can force them to do it (this is academic right now, since they already did the [pretty trivial] work). If the systemd people did not wanted to do the job, then, since you can't force them, the people *not* wanting systemd would be the ones required to do it. And that makes absolutely no sense. I think we agree, but you keep saying we don't... ;) The difference is, since OpenRC is the default, all of the existing profiles are, by definition, OpenRC based profiles. So, people who don't want systemd simply have to do... nothing! OK, I see your point. As I said before, it is people who want systemd who currently have to 'do something', and that is as it should be, unless/until the default of OpenRC is changed to systemd. Agreed. Regards. Been following along, jumping in late. That does settle the issue with regard to Gentoo 'defaults' for now. As I see it, if you are a desktop [l]user, then go ahead and use a quick systemd default. It's good enough. And Gnome folks, from what I understood, didn't have an easy opt-out choice, really. At least not easy enough for me to grok right away. Anyway, some arguments on the other branches of this thread got me thinking. Take the binary log files. This seems to be something we all understand to some extent (as compared to init systems, say), whether a tinkerer or enterprise user. There's now something corporate sitting between me and the evil crap coming out of my daemons. Who logs the loggers? My thought was, well, say if someone else, some other, unrelated team entirely, was maintaining a codebase for handling that logging data, that's a way out of the monoculture of systemd that would give some peace of mind. If they, as also smart, talented coders began to disagree, they might have capacity to keep the project in bounds. So, for the hell of it, I just went to have a look at what the deal might be with that binary data that hangs around and dumps to disk, maybe, in one format or another. This document explains the basic structure of the file format on disk. We are making this available primarily to allow review and provide documentation. Note that the actual implementation in the systemd codebase is the only ultimately authoritative description of the format, so if this document and the code disagree, the code is right. That said we'll of course try hard to keep this document up-to-date and accurate. Instead of implementing your own reader or writer for journal files we ask you to use the Journal's native C API to access these files. It provides you with full access to the files, and will not withhold any data. If you find a limitation, please ping us and we might add some additional interfaces for you. From: http://www.freedesktop.org/wiki/Software/systemd/journal-files/ Wow, that makes me feel all warm, fuzzy and secure as shit. I think I just fell asleep for a moment. (My background would make me read this, essentially advertising copy, as a classic example of perverse use of semiotics, thus raising the reading on my B.S. meter. But I digress.) The best part is the conclusion: *If you find a limitation, please ping us and we might add some additional interfaces for you.* Please! Ping! Second best is, we'll of course try hard to keep this document up-to-date and accurate. Of course. So. If I were paranoid, or even mildly concerned, I'd take this to mean two things: One. There is, or could be, data that the systemd logging magic box doesn't give you an interface for. Unless you know what it is, then they might let you log it. Or you can, of course, contribute code, I'm sure. Though, Note that the actual implementation in the systemd codebase is the only ultimately authoritative description of the format. Two. If I want to have a reasonable degree of surety that the code isn't collecting data that isn't interfaced for you in the journalcontrol, I'd have to delve into the codebase for systemd. Which, I'm sure, is a piece of cake. And, of course, I, and my security team, have to review the basic code on my GNU/Linux F[L]OSS machine regularly anyway. Oh, wait... No I don't. The beauty of the development model I trust is a diverse group of folks with a *variety of interests* contributing to various areas of code, in turn reviewed by some set of that same varied group, eventually committed and
Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie
On 02/15/2014 08:09 PM, walt wrote: On 02/15/2014 12:30 PM, Daniel Campbell wrote: The social tactics at work from the systemd team (and verily, other Red Hat projects like GNOME) are reminiscent of Microsoft through the use of the Embrace, Extend, Extinguish methodology. I certainly share your hostility towards M$ for suppressing competition. Red Hat, like M$, is a for-profit corporation, so I share your suspicion that they want to suppress their competitors (though I don't know who their competitors are). But comparing a completely closed-source shop like M$ to any open source company leaves me feeling uneasy. I can't find the exact argument to explain my unease, but I'm hoping someone else will jump in with a more rational argument. I think I understand where you're coming from. How can they compare when Red Hat releases their source under a liberating license while MS locks it down behind closed doors? That's missing the point, though. In the FOSS world, that's the bait, so to speak. The wolf in sheep's clothing. Red Hat can release (or hack on) a bunch of attractive software or features, get people interested (so interested that, say, the majority of distros depend on it *wink wink*), and then use that influence to indirectly control where FOSS moves. By striking the weakest part of the stack (sysv probably *did* need a good replacement, but not one as ambitious as systemd) and digging down into the kernel level (kdbus), Red Hat devs will now have a very influential role in the FOSS world. This will in turn generate interest (and thus profit) in Red Hat. It's marginally clever, but so clearly obvious at the same time. It's sad (to me) that the community didn't see it coming. Those who did have been written off as conspiracy theorists or FUDders. Time will reveal all. ~Daniel
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Thu, 20 Feb 2014 15:37:09 -0800 Michael Higgins li...@evolone.org wrote: Okay, I'll go re-wire my tin hat now. Hope someone found this amusing. One other thought I'd has was, well, as long as systemd doesn't, like, implement some kind of net protocol, so to make it possible to ship logs from systemdjournalcontrol. I mean, so what if then it just sits there doing its job, more or less. You can even offload the job to your favourite logger, and it just sits there, pretty much inoffensively in the pid 1 family. Then I read this: I am curently working on getting log syncing via both a PUSH and PULL model done. This will be based one existing protocols and standards as much as we can (SSH or HTTP/HTTPS as transport, and JSON and more as payload), and is flexible for others to hook into. For example, I think it would be cool if greylog2 and similar software would just pull the data out of the journal on its own, simply via HTTP/JSON. We make everything available to make this smooth, i.e. we provide clients with stable cursors which they can use to restart operation. So, I don't know. That 'journalctl' seems to be really just a front-end to some routines actuall coded in sytemd. So, I guess, windows all over again? Really, a net protocol at that level? I'm sure there's no way to exploit that. What I do know is, that if any point I work again in IT, it will just be part of the way it is done, for the same reasons most shops don't use Gentoo, for example. No one will blame you for using whatever, if pretty much everyone else does so too. Plus, if there's some massive codebase with a flaw causing a security breach, you're not alone. But, seriously, flawed (carnivorous or nefarious) by design does seem to be the upshot here, the more I read about the design decisions. I don't think I've presented any compelling argument against anyone else using it, per se, more than questioning the logic of it becoming ubiquitous. It does seem to solve a lot of real world problems, in one way, or another. And I'm done looking at it, I think, and will leave it to others to take my notes with the grains of salt required. For me, I don't really have a need for what it offers, nor a real world need to worry about possible implications of its design or rate of adoption. Cheers, Cheers, - mykhyggz
Re: [gentoo-user] systemd and USE=static
On Thu, 20 Feb 2014 16:59:39 -0500, Mike Gilbert wrote: It seems the systemd profile masks the static and static-libs USE flags, which are needed by crytsetup and lvm for my initramfs, which mounts / from a LUKS partition. Forcing an unmask of these flags in /etc/portage/profile did no good because when those packages are built with USE=static they require a virtual/udev with matching flags, which systemd cannot provide. I would recommend using an initramfs which includes the necessary shared libraries. I'm pretty sure dracut and genkernel-next support this. If you roll your own initramfs, this isn't terribly difficult either -- just use ldd to figure out which files you need, and copy them to /lib or /lib64 in the intiramfs image. That was the answer. I knocked up a script that ldd'd the files included in the initramfs and added them to its config file. Thanks. -- Neil Bothwick WinErr 006: Malicious error - Desqview found on drive signature.asc Description: PGP signature
Re: [gentoo-user] Fwd: How about the gentoo server or cluster in production environment?
the advantage of clustering servers though is you can take one out and update it. if you use a distributed compliation [1] and tell portage to keep the binaries [2] you can take a few out and do them together, then the remainder do not require compilation as the compile has been It is True. I didnt throught on thath. :) That is such total FUD I just can't even say anything else about it without using some unsavory words. You no need to be disrespectfull... It just was my opinion, and everybody are here to learn... Everybody say good points. I think it is just a matter of taste. I hope get the chance to try gentoo as server someday. For now, i just stay in debian. (And my lovely gentoo as desktop, of course). Bye! ;)
Re: [gentoo-user] Fwd: How about the gentoo server or cluster in production environment?
On 21 Feb 2014 06:33, Facundo Curti facu.cu...@gmail.com wrote: the advantage of clustering servers though is you can take one out and update it. if you use a distributed compliation [1] and tell portage to keep the binaries [2] you can take a few out and do them together, then the remainder do not require compilation as the compile has been It is True. I didnt throught on thath. :) That is such total FUD I just can't even say anything else about it without using some unsavory words. You no need to be disrespectfull... It just was my opinion, and everybody are here to learn... Everybody say good points. I think it is just a matter of taste. I hope get the chance to try gentoo as server someday. For now, i just stay in debian. (And my lovely gentoo as desktop, of course). Bye! ;) Just my two cents - I've been using gentoo on my servers as well as on client servers since about 2.5+ years and never had any issues.
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Thu, Feb 20, 2014 at 5:37 PM, Michael Higgins li...@evolone.org wrote: On Thu, 20 Feb 2014 15:38:46 -0600 Canek Peláez Valdés can...@gmail.com wrote: On Thu, Feb 20, 2014 at 3:22 PM, Tanstaafl tansta...@libertytrek.org wrote: On 2014-02-20 4:04 PM, Canek Peláez Valdés can...@gmail.com wrote: No, actually, I think whatever is defined as the current default should dictate which group should be required to do the work. I think this is where we think differently (regarding this particular point). The work must be done by *whomever* wants to do the job. So if the systemd people want to do a profile that's fine (and this already happened); but if they don't want to, nobody can force them to do it (this is academic right now, since they already did the [pretty trivial] work). If the systemd people did not wanted to do the job, then, since you can't force them, the people *not* wanting systemd would be the ones required to do it. And that makes absolutely no sense. I think we agree, but you keep saying we don't... ;) The difference is, since OpenRC is the default, all of the existing profiles are, by definition, OpenRC based profiles. So, people who don't want systemd simply have to do... nothing! OK, I see your point. As I said before, it is people who want systemd who currently have to 'do something', and that is as it should be, unless/until the default of OpenRC is changed to systemd. Agreed. Regards. Been following along, jumping in late. That does settle the issue with regard to Gentoo 'defaults' for now. As I see it, if you are a desktop [l]user, then go ahead and use a quick systemd default. It's good enough. And Gnome folks, from what I understood, didn't have an easy opt-out choice, really. At least not easy enough for me to grok right away. Anyway, some arguments on the other branches of this thread got me thinking. Take the binary log files. This seems to be something we all understand to some extent (as compared to init systems, say), whether a tinkerer or enterprise user. There's now something corporate sitting between me and the evil crap coming out of my daemons. Who logs the loggers? My thought was, well, say if someone else, some other, unrelated team entirely, was maintaining a codebase for handling that logging data, that's a way out of the monoculture of systemd that would give some peace of mind. If they, as also smart, talented coders began to disagree, they might have capacity to keep the project in bounds. So, for the hell of it, I just went to have a look at what the deal might be with that binary data that hangs around and dumps to disk, maybe, in one format or another. This document explains the basic structure of the file format on disk. We are making this available primarily to allow review and provide documentation. Note that the actual implementation in the systemd codebase is the only ultimately authoritative description of the format, so if this document and the code disagree, the code is right. That said we'll of course try hard to keep this document up-to-date and accurate. Instead of implementing your own reader or writer for journal files we ask you to use the Journal's native C API to access these files. It provides you with full access to the files, and will not withhold any data. If you find a limitation, please ping us and we might add some additional interfaces for you. From: http://www.freedesktop.org/wiki/Software/systemd/journal-files/ Wow, that makes me feel all warm, fuzzy and secure as shit. I think I just fell asleep for a moment. (My background would make me read this, essentially advertising copy, as a classic example of perverse use of semiotics, thus raising the reading on my B.S. meter. But I digress.) The best part is the conclusion: *If you find a limitation, please ping us and we might add some additional interfaces for you.* Please! Ping! Second best is, we'll of course try hard to keep this document up-to-date and accurate. Of course. So. If I were paranoid, or even mildly concerned, I'd take this to mean two things: One. There is, or could be, data that the systemd logging magic box doesn't give you an interface for. Unless you know what it is, then they might let you log it. Or you can, of course, contribute code, I'm sure. Though, Note that the actual implementation in the systemd codebase is the only ultimately authoritative description of the format. Two. If I want to have a reasonable degree of surety that the code isn't collecting data that isn't interfaced for you in the journalcontrol, I'd have to delve into the codebase for systemd. Which, I'm sure, is a piece of cake. And, of course, I, and my security team, have to review the basic code on my GNU/Linux F[L]OSS machine regularly anyway. Oh, wait... No I don't. The beauty of the development model I trust is a diverse group of folks with a *variety
Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie
On Thu, Feb 20, 2014 at 6:08 PM, Daniel Campbell li...@sporkbox.us wrote: On 02/15/2014 08:09 PM, walt wrote: On 02/15/2014 12:30 PM, Daniel Campbell wrote: The social tactics at work from the systemd team (and verily, other Red Hat projects like GNOME) are reminiscent of Microsoft through the use of the Embrace, Extend, Extinguish methodology. I certainly share your hostility towards M$ for suppressing competition. Red Hat, like M$, is a for-profit corporation, so I share your suspicion that they want to suppress their competitors (though I don't know who their competitors are). But comparing a completely closed-source shop like M$ to any open source company leaves me feeling uneasy. I can't find the exact argument to explain my unease, but I'm hoping someone else will jump in with a more rational argument. I think I understand where you're coming from. How can they compare when Red Hat releases their source under a liberating license while MS locks it down behind closed doors? That's missing the point, though. No, it's not. In the FOSS world, that's the bait, so to speak. The wolf in sheep's clothing. Red Hat can release (or hack on) a bunch of attractive software or features, get people interested (so interested that, say, the majority of distros depend on it *wink wink*), and then use that influence to indirectly control where FOSS moves. By striking the weakest part of the stack (sysv probably *did* need a good replacement, but not one as ambitious as systemd) and digging down into the kernel level (kdbus), Red Hat devs will now have a very influential role in the FOSS world. This will in turn generate interest (and thus profit) in Red Hat. First of all, you do realize that Greg Kroah-Hartman, the primary author of kdbus, works for the Linux Foundation, right? Not RedHat. Second, good for RedHat if they can turn a profit. Meanwhile the code from the whole stack is free, and anyone willing and able can fork it and use, enhance, or replace any part of it. And yes, I said replace. So, again, the comparison makes no sense at all. It's marginally clever, but so clearly obvious at the same time. It's sad (to me) that the community didn't see it coming. So you are saying we are idiots? Or just naive? Or both? And *all* of us who use systemd and think is a great idea? Damn, if only we had knew. Too bad you didn't come before to open our eyes to this undeniable truth. Now it's too late, the sky is falling and the world will end on fire and brim. Those who did have been written off as conspiracy theorists or FUDders. Time will reveal all. Indeed it will. Wanna bet a beer? Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Thu, Feb 20, 2014 at 6:16 PM, Michael Higgins li...@evolone.org wrote: On Thu, 20 Feb 2014 15:37:09 -0800 Michael Higgins li...@evolone.org wrote: Okay, I'll go re-wire my tin hat now. Hope someone found this amusing. One other thought I'd has was, well, as long as systemd doesn't, like, implement some kind of net protocol, so to make it possible to ship logs from systemdjournalcontrol. Of course it has; you can configure the journal to send the logs of different machines to a central server, so even if the machine gets compromised, the logs just prior to the attack are available for analysis. If you are *really* interested in the topic, take a look at this neat LWN article about it [1]. [ sniped the rest of the conspiracy theory ] Regards. [1] http://lwn.net/Articles/512895/ -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie
On 02/20/2014 07:42 PM, Canek Peláez Valdés wrote: On Thu, Feb 20, 2014 at 6:08 PM, Daniel Campbell li...@sporkbox.us wrote: On 02/15/2014 08:09 PM, walt wrote: On 02/15/2014 12:30 PM, Daniel Campbell wrote: The social tactics at work from the systemd team (and verily, other Red Hat projects like GNOME) are reminiscent of Microsoft through the use of the Embrace, Extend, Extinguish methodology. I certainly share your hostility towards M$ for suppressing competition. Red Hat, like M$, is a for-profit corporation, so I share your suspicion that they want to suppress their competitors (though I don't know who their competitors are). But comparing a completely closed-source shop like M$ to any open source company leaves me feeling uneasy. I can't find the exact argument to explain my unease, but I'm hoping someone else will jump in with a more rational argument. I think I understand where you're coming from. How can they compare when Red Hat releases their source under a liberating license while MS locks it down behind closed doors? That's missing the point, though. No, it's not. In the FOSS world, that's the bait, so to speak. The wolf in sheep's clothing. Red Hat can release (or hack on) a bunch of attractive software or features, get people interested (so interested that, say, the majority of distros depend on it *wink wink*), and then use that influence to indirectly control where FOSS moves. By striking the weakest part of the stack (sysv probably *did* need a good replacement, but not one as ambitious as systemd) and digging down into the kernel level (kdbus), Red Hat devs will now have a very influential role in the FOSS world. This will in turn generate interest (and thus profit) in Red Hat. First of all, you do realize that Greg Kroah-Hartman, the primary author of kdbus, works for the Linux Foundation, right? Not RedHat. Second, good for RedHat if they can turn a profit. Meanwhile the code from the whole stack is free, and anyone willing and able can fork it and use, enhance, or replace any part of it. And yes, I said replace. So, again, the comparison makes no sense at all. It's marginally clever, but so clearly obvious at the same time. It's sad (to me) that the community didn't see it coming. So you are saying we are idiots? Or just naive? Or both? And *all* of us who use systemd and think is a great idea? Damn, if only we had knew. Too bad you didn't come before to open our eyes to this undeniable truth. Now it's too late, the sky is falling and the world will end on fire and brim. Those who did have been written off as conspiracy theorists or FUDders. Time will reveal all. Indeed it will. Wanna bet a beer? Regards. Indeed, Greg doesn't work for Red Hat. Prior to working for LF, however, he worked for Novell, another for-profit Linux company. Moot point. Businesses tend to do favors for other businesses. What makes you think Red Hat hasn't given LF some money at some point? Further, isn't Lennart friends with Greg? Isn't that how he got udev into systemd, since Greg maintained udev before it was merged into systemd? Tell the full story if you're going to bring it up. I will refrain from stooping to the level of petty insults... but yes, collectively the FOSS community at large has *terrible* social awareness within its own ecosystem and would not see an agenda coming until it was too late and they had to fork or rebuild. It has nothing to do with me; it has everything to do with foresight. And the FOSS world is lacking in that. Those that have it are outnumbered by those who get distracted by shiny objects and if they care about the future of FOSS, it's only in a superficial sense. FOSS is not just code, it's culture too.
Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie
On Thu, Feb 20, 2014 at 8:39 PM, Daniel Campbell li...@sporkbox.us wrote: On 02/20/2014 07:42 PM, Canek Peláez Valdés wrote: On Thu, Feb 20, 2014 at 6:08 PM, Daniel Campbell li...@sporkbox.us wrote: On 02/15/2014 08:09 PM, walt wrote: On 02/15/2014 12:30 PM, Daniel Campbell wrote: The social tactics at work from the systemd team (and verily, other Red Hat projects like GNOME) are reminiscent of Microsoft through the use of the Embrace, Extend, Extinguish methodology. I certainly share your hostility towards M$ for suppressing competition. Red Hat, like M$, is a for-profit corporation, so I share your suspicion that they want to suppress their competitors (though I don't know who their competitors are). But comparing a completely closed-source shop like M$ to any open source company leaves me feeling uneasy. I can't find the exact argument to explain my unease, but I'm hoping someone else will jump in with a more rational argument. I think I understand where you're coming from. How can they compare when Red Hat releases their source under a liberating license while MS locks it down behind closed doors? That's missing the point, though. No, it's not. In the FOSS world, that's the bait, so to speak. The wolf in sheep's clothing. Red Hat can release (or hack on) a bunch of attractive software or features, get people interested (so interested that, say, the majority of distros depend on it *wink wink*), and then use that influence to indirectly control where FOSS moves. By striking the weakest part of the stack (sysv probably *did* need a good replacement, but not one as ambitious as systemd) and digging down into the kernel level (kdbus), Red Hat devs will now have a very influential role in the FOSS world. This will in turn generate interest (and thus profit) in Red Hat. First of all, you do realize that Greg Kroah-Hartman, the primary author of kdbus, works for the Linux Foundation, right? Not RedHat. Second, good for RedHat if they can turn a profit. Meanwhile the code from the whole stack is free, and anyone willing and able can fork it and use, enhance, or replace any part of it. And yes, I said replace. So, again, the comparison makes no sense at all. It's marginally clever, but so clearly obvious at the same time. It's sad (to me) that the community didn't see it coming. So you are saying we are idiots? Or just naive? Or both? And *all* of us who use systemd and think is a great idea? Damn, if only we had knew. Too bad you didn't come before to open our eyes to this undeniable truth. Now it's too late, the sky is falling and the world will end on fire and brim. Those who did have been written off as conspiracy theorists or FUDders. Time will reveal all. Indeed it will. Wanna bet a beer? Regards. Indeed, Greg doesn't work for Red Hat. Prior to working for LF, however, he worked for Novell, another for-profit Linux company. Moot point. Businesses tend to do favors for other businesses. What makes you think Red Hat hasn't given LF some money at some point? Further, isn't Lennart friends with Greg? Isn't that how he got udev into systemd, since Greg maintained udev before it was merged into systemd? Tell the full story if you're going to bring it up. So, now it's RedHat, Novell and the Linux Foundation. Anyone else? The NSA? The CIA? The Cobra Commander? The Cobra Commander is always involved. I will refrain from stooping to the level of petty insults... but yes, collectively the FOSS community at large has *terrible* social awareness within its own ecosystem and would not see an agenda coming until it was too late and they had to fork or rebuild. It has nothing to do with me; it has everything to do with foresight. And the FOSS world is lacking in that. Those that have it are outnumbered by those who get distracted by shiny objects and if they care about the future of FOSS, it's only in a superficial sense. Gee, if I though that about our community, then I would not want to be part of it. Good think I don't think like you. FOSS is not just code, it's culture too. Exactly, and it seems you miss the whole point about the FOSS culture too. I will not answer any more of your mails until you present some actual evidence about this big bad group of people under the guidance of shady corporations trying to take advantage of the poor, stupid, social inept FOSS community. I do not care about hearsay. I care about facts, and technological arguments. If you do not have any of those, I'm done with you in this thread. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie
On 02/20/2014 08:53 PM, Canek Peláez Valdés wrote: On Thu, Feb 20, 2014 at 8:39 PM, Daniel Campbell li...@sporkbox.us wrote: On 02/20/2014 07:42 PM, Canek Peláez Valdés wrote: On Thu, Feb 20, 2014 at 6:08 PM, Daniel Campbell li...@sporkbox.us wrote: On 02/15/2014 08:09 PM, walt wrote: On 02/15/2014 12:30 PM, Daniel Campbell wrote: The social tactics at work from the systemd team (and verily, other Red Hat projects like GNOME) are reminiscent of Microsoft through the use of the Embrace, Extend, Extinguish methodology. I certainly share your hostility towards M$ for suppressing competition. Red Hat, like M$, is a for-profit corporation, so I share your suspicion that they want to suppress their competitors (though I don't know who their competitors are). But comparing a completely closed-source shop like M$ to any open source company leaves me feeling uneasy. I can't find the exact argument to explain my unease, but I'm hoping someone else will jump in with a more rational argument. I think I understand where you're coming from. How can they compare when Red Hat releases their source under a liberating license while MS locks it down behind closed doors? That's missing the point, though. No, it's not. In the FOSS world, that's the bait, so to speak. The wolf in sheep's clothing. Red Hat can release (or hack on) a bunch of attractive software or features, get people interested (so interested that, say, the majority of distros depend on it *wink wink*), and then use that influence to indirectly control where FOSS moves. By striking the weakest part of the stack (sysv probably *did* need a good replacement, but not one as ambitious as systemd) and digging down into the kernel level (kdbus), Red Hat devs will now have a very influential role in the FOSS world. This will in turn generate interest (and thus profit) in Red Hat. First of all, you do realize that Greg Kroah-Hartman, the primary author of kdbus, works for the Linux Foundation, right? Not RedHat. Second, good for RedHat if they can turn a profit. Meanwhile the code from the whole stack is free, and anyone willing and able can fork it and use, enhance, or replace any part of it. And yes, I said replace. So, again, the comparison makes no sense at all. It's marginally clever, but so clearly obvious at the same time. It's sad (to me) that the community didn't see it coming. So you are saying we are idiots? Or just naive? Or both? And *all* of us who use systemd and think is a great idea? Damn, if only we had knew. Too bad you didn't come before to open our eyes to this undeniable truth. Now it's too late, the sky is falling and the world will end on fire and brim. Those who did have been written off as conspiracy theorists or FUDders. Time will reveal all. Indeed it will. Wanna bet a beer? Regards. Indeed, Greg doesn't work for Red Hat. Prior to working for LF, however, he worked for Novell, another for-profit Linux company. Moot point. Businesses tend to do favors for other businesses. What makes you think Red Hat hasn't given LF some money at some point? Further, isn't Lennart friends with Greg? Isn't that how he got udev into systemd, since Greg maintained udev before it was merged into systemd? Tell the full story if you're going to bring it up. So, now it's RedHat, Novell and the Linux Foundation. Anyone else? The NSA? The CIA? The Cobra Commander? The Cobra Commander is always involved. I will refrain from stooping to the level of petty insults... but yes, collectively the FOSS community at large has *terrible* social awareness within its own ecosystem and would not see an agenda coming until it was too late and they had to fork or rebuild. It has nothing to do with me; it has everything to do with foresight. And the FOSS world is lacking in that. Those that have it are outnumbered by those who get distracted by shiny objects and if they care about the future of FOSS, it's only in a superficial sense. Gee, if I though that about our community, then I would not want to be part of it. Good think I don't think like you. FOSS is not just code, it's culture too. Exactly, and it seems you miss the whole point about the FOSS culture too. I will not answer any more of your mails until you present some actual evidence about this big bad group of people under the guidance of shady corporations trying to take advantage of the poor, stupid, social inept FOSS community. I do not care about hearsay. I care about facts, and technological arguments. If you do not have any of those, I'm done with you in this thread. Regards. Firstly, you don't control whether or not I send an e-mail. The high horse is completely unnecessary. This particular thread (from walt) had nothing to do with you directly, so I don't know why you're getting so upset. You're free to hit the Delete button in your e-mail client or add me to your spam filter. I said nothing
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Thu, Feb 20, 2014 at 8:53 PM, Tanstaafl tansta...@libertytrek.org wrote: On 2014-02-20 12:43 AM, Canek Peláez Valdés can...@gmail.com wrote: On Wed, Feb 19, 2014 at 6:38 AM, Tanstaafltansta...@libertytrek.org wrote: On 2014-02-19 2:04 AM, Daniel Campbellli...@sporkbox.us wrote: For such a profile to be legitimate, systemd would have to be chosen as the default. Ridiculous. Forget about Canek's rant... This is about *choice*. Also, I would argue the *opposite of what Canek is saying in this last rant... Tanstaafl, can we please not use terms like rants? I'm just giving my opinion, trying to be respectful and civil to the others participants in this thread. I would appreciate if you do the same to me. Sorry, Canek, no offense was intended, but if you go back and re-read your 'extremely overly enthusiastic' post (this plus the content is why I referred to it as a 'rant'), while I agree with most everything you said, your primary point - that it should be the people who *don't* want systemd doing all of the work - was backwards, and that was what I wanted to point out. I'm afraid this is the part that's backwards. So, please, don't take it as an insult. In fact you have done a very good job of patiently spelling out the advantages of systemd, to the point I'm no longer afraid of it taking over and devouring the linux world. If systemd truly is, as you say taking over and devouring the linux world such that the majority of distro maintainers are individually choosing to use a feature or two from it, then yes, it definitely is the job of people who want to opt out of it to do the work. If Gnome wants systemd, and you don't, but you want to continue using Gnome, it's _your_ job to look for a method or patch or package or script that makes it work. If udev wants systemd, and you don't, but you want to continue using udev, it's _your_ job to look for a method or patch or package or script that makes it work. If foo wants systemd, and you don't, but you want to continue using foo, it's _your_ job to look for a method or patch or package or script that makes it work. If everybody else wants to use systemd but you, it's your job to keep your system working the way you want to. Nobody's going to go out of their way to specifically and targettedly break your system, because you don't like their way. However, you can co-opt some package maintainer's way and say he's obligated to make a pure and systemd uncorrupted system for you. Because he's not. Bottom line: since Gentoo's default and primary init system is (and hopefully will be for a very long time) OpenRC, it is on the systemd folks to do the work to get systemd fully supported. systemd IS supported and working. The problem arises when there are people that want to push for a system with no systemd whatsoever and act like it's the systemd maintainer's job to make that happen. -- This email is:[ ] actionable [ ] fyi[x] social Response needed: [ ] yes [x] up to you [ ] no Time-sensitive: [ ] immediate[ ] soon [x] none
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
Mark David Dumlao wrote: If udev wants systemd, and you don't, but you want to continue using udev, it's _your_ job to look for a method or patch or package or script that makes it work. That's already done. It's called eudev. :-D Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Fri, 21 Feb 2014 11:36:15 +0800 Mark David Dumlao wrote: [...] So, please, don't take it as an insult. In fact you have done a very good job of patiently spelling out the advantages of systemd, to the point I'm no longer afraid of it taking over and devouring the linux world. If systemd truly is, as you say taking over and devouring the linux world such that the majority of distro maintainers are individually choosing to use a feature or two from it, then yes, it definitely is the job of people who want to opt out of it to do the work. If Gnome wants systemd, and you don't, but you want to continue using Gnome, it's _your_ job to look for a method or patch or package or script that makes it work. 1. I do _not_ want to use Gnome (and never used it) as DE. 2. Someone called Lennart was a long-time Gnome contributor before Gnome required systemd without alternative. Coincidence? I don't believe in them. I trust probabilities and statistics. If udev wants systemd, and you don't, but you want to continue using udev, it's _your_ job to look for a method or patch or package or script that makes it work. We have eudev fork which is clean from systemd crapware and works perfectly on production setutps. If foo wants systemd, and you don't, but you want to continue using foo, it's _your_ job to look for a method or patch or package or script that makes it work. If everybody else wants to use systemd but you, it's your job to keep your system working the way you want to. Nobody else requires systemd mandatory now as to my knowledge. Nobody's going to go out of their way to specifically and targettedly break your system, because you don't like their way. However, you can co-opt some package maintainer's way and say he's obligated to make a pure and systemd uncorrupted system for you. Because he's not. Bottom line: since Gentoo's default and primary init system is (and hopefully will be for a very long time) OpenRC, it is on the systemd folks to do the work to get systemd fully supported. systemd IS supported and working. The problem arises when there are people that want to push for a system with no systemd whatsoever and act like it's the systemd maintainer's job to make that happen. OpenRC is default in Gentoo now, and it is my best hope it will be. Thus anyone willing to use something else should do an appropriate job. Best regards, Andrew Savchenko pgpiEf5yXsVgJ.pgp Description: PGP signature
Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie
20.02.2014 19:24, Alan McKinnon пишет:
On 20/02/2014 13:53, Yuri K. Shatroff wrote:
I don't need such 'solutions' to non-existent problems. But if there
were a *real* necessity to pretty-print a log's tail in service status,
I think it would have been a matter of a proper setup (i.e. the service
using syslog, hence a defined log format) and not a heck more complicated.
Definetly not a 5-minutes job.
5 minutes is even too much to type sort of
tail -${LINES} ${SERVICE}.log
if you know where to look up LINES and SERVICE.
You've never actually tried this, right?
You probably misunderstood. I don't *intend* to try this myself with
existing tools, I'm speaking of the init scripts modification. I say
that this modification of e.g. OpenRC, if required, would be done quite
easily with some assumptions.
Your idea instantly fails as the rc-service author has no idea of what
you defined ${SERVICE} to be and no way to determine what it is now.
Yes, the rc-service author does not have any idea because he is not
requested to.
${SERVICE} obviously comes from `rc-service status ${SERVICE}` .
The result (e.g. tail -n {$LINES} ${SERVICE}.log) is achieved by:
1. putting LINES= in /etc/conf.d/${SERVICE}
2. setting up ${SERVICE}.log with syslog. (or putting LOGFILE=... and
doing `tail -n ${LINES} ${LOGFILE}, or even LAST_LOG_CMD=`mysql -qe
'SELECT ... FROM log.log ORDER BY date DESC LIMIT ${LINES}'`, or *whatever*)
3. adding this `tail -n ...` or whatever call to the init script .
4. voila.
If you feel I'm again entirely wrong please point out why.
How are you going to deal with the situation with a big busy daemon that
immediately starts serving requests when started (i.e. with very little
delay)?
Either you or I seem to have misunderstood again.
The problem in question IMO was to add the output of last N log entries
to `*service status` analogous to systemctl status.
When you do tail -n $FILE, don't you *always* get the last N lines of
the file at the moment of issuing the cmd, regardless whether the file
is being added a million lines per second. I don't think that journalctl
can essentially work differently.
By the time grep, sed, awk and friends have gotten around to making
their way through a log file of varying size, the entries that apply to
restart can easy be many hundreds of log lines prior.
Why do you refer to restart?
Canek wrote:
systemctl status apache2.service
(see [2]) will print the status of the Apache web server, and also
the last lines from the logs. You can control how many lines
I don't notice anything about restart here. Just print out the last N lines.
If the question were about [re]start logs, and if in general you are
getting millions of entries written to the logs, you could use DBMS (not
necessarily relational). Maybe this *does* require some mess to setup
(we did it back in times of SunOS), but it could be resolved with
OpenRC/any SysV/BSD init (at the init-scripts level) if really necessary.
Am I wrong?
I have done this, and it does not work. I got a result and it's
relaible, but you don't want to know what it took. It's also highly
customized and useless to anything other than my highly customized setup.
Well, if you have to set up one system from scratch then probably it's
easier to use one generalized tool. But if you have an already
long-working setup which suits your needs, I believe it's relatively
easy to deploy it on other systems.
I don't like truisms but there is no generic setup suitable for
everything. Neither is systemd-journald.
--
Regards,
Yuri K. Shatroff
Re: [gentoo-user] Fwd: How about the gentoo server or cluster in production environment?
Thanks for your help. The choice for HPC can be more free. I prepare to try it in datacenter, for FTP first, and then web server, mail server and so forth. Of course, I still think it's better to use rhel or suse for database, CRM and others. On 2014年02月20日 22:35, Andrew Savchenko wrote: Hi, On Thu, 20 Feb 2014 07:40:59 +0800 Franklin Wang wrote: I'm not familiar with gentoo server and cluster. So could you tell me the experience about them? Thanks. We have successful experience with Gentoo on both production servers (someone call this area enterprise, though I dislike such name) and HPC setups. In short, Procs: - fine-tuned setups; - really large choice of components; - high-performance setups (especially rocks for HPC); - reduced attack surface; - nontrivial attack surface; - large system updates easy (comparted to e.g. RHEL4 - RHEL5 migration); - easier to add and maintain out-of-tree software. Cons: - much longer time for initial setup; - harder to apply routine updates; - poorly suitable for tasks like: create me this new service ASAP (for which you don't have prepared images), preferably yesterday. Other notes: - requires more qualified personnel to maintain. Best regards, Andrew Savchenko -- skype:touch21st, Gtalk:touch21st, Yahoo/MSN:franklinwan...@yahoo.com, Xing/Linkedin:Franklin Wang
Re: [gentoo-user] Fwd: How about the gentoo server or cluster in production environment?
Thanks a lot. On 2014年02月21日 02:41, Andreas K. Huettel wrote: Original Message Subject: How about the gentoo server or cluster in production environment? Date:Fri, 29 Nov 2013 09:41:28 +0800 From:Franklin Wang touch2...@gmail.com To: gentoo-ser...@lists.gentoo.org, gentoo-clus...@lists.gentoo.org Hi all, I'm not familiar with gentoo server and cluster. So could you tell me the experience about them? Thanks. There are some quite decent clusters running Gentoo. See the homepage of the cluster team, https://www.gentoo.org/proj/en/cluster/ and also the link there Clusters running Gentoo. -- skype:touch21st, Gtalk:touch21st, Yahoo/MSN:franklinwan...@yahoo.com, Xing/Linkedin:Franklin Wang
Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie
On Thu, 20 Feb 2014 18:08:43 -0600 Daniel Campbell wrote: It's marginally clever, but so clearly obvious at the same time. It's sad (to me) that the community didn't see it coming. Those who did have been written off as conspiracy theorists or FUDders. Time will reveal all. Indeed time reveals everything and part of this foiled plot revealed itself two days ago. It was said earlier in the list by systemd supporters, that this project is modular, fine split to binaries and thus critical issues in the pid 1 are not that likely. And just look at systemd-209 release notes: http://lists.freedesktop.org/archives/systemd-devel/2014-February/017146.html [quote] We merged libsystemd-journal.so, libsystemd-id128.so, libsystemd-login and libsystemd-daemon into a a single libsystemd.so to reduce code duplication and avoid cyclic dependencies (see below). [/quote] So all talks about systemd being modular are nothing more than nonsense. Guess what will happen on segfault in libsystemd.so? Segfaults in pid 1 are so nice to bear... And Canek please talk no more about how talented systemd programmers are or even about how professional they are, because they're no longer. They failed a trivial textbook example: what should one do when libraries A and B have some common code and cyclic deps? Push common code to library C. That's the Unix way and secure way. Creating single bloated library will help in neither fencing nor debugging, nor code audit. It looks like to me that ultimate goal of systemd is to consume as much system and user tools and interfaces as possible. Perhaps, in the ideal systemd world there will be nothing but linux-systemd kernel and systemd-stuff userspace. Shell communication will extinct, all major application and daemons will be converted to systemd modules. Of course this goal will be never achieved as-is, but one may consider it as an asymptote of their actions. Best regards, Andrew Savchenko pgpef2uhhHI0s.pgp Description: PGP signature
