7:53 a.m.
Making the rounds of various technical mailing lists yesterday, with a
subject that's typically a variation of "Just for yucks, and giggles" is a
link to a commit to systemd's git, adding DNS caching to systemd; in one,
huge 857 line glop. Here's its entire commit message: "resolved: add DNS
cache".
And, it's beauty to read. Made me teary-eyed to know that systemd will cache
my DNS queries. Not sure why systemd, all of a sudden, needs to make DNS
queries. But if it does, it's going to cache them now! Such a sight to
behold makes my heart skip a beat: now, not just bind, or pretty much every
DNS server that automatically caches DNS for you – but so will systemd!
But, seriously folks, systemd's DNS caching achieves absolutely 100%
nothing. Really. Surprised? Well, you'll be shocked to know that the DNS
server that systemd queries for that DNS RR, such as the stock "bind",
already automatically caches all recursive DNS replies!! systemd's own
caching produces absolutely zero useful results. On the oft chance that it
sends a query for a non-cached RR, the local DNS server will cache the
response, before returning it to systemd, and then use the cached response
for all future queries. That's what DNS servers do: provide caching for
local clients. It's inherent in DNS's design: DNS was explicitly designed to
use aggressive caching, it's an internet-wide, distributed, locally cached
database.
Isn't modern technology amazing?
I'm willing to consider the possibility that I missed something obvious,
some obvious value-added result from caching DNS RRs directly by systemd,
and I'll stick around for someone to enlighten me; or if Occam's razor
applies, and the author of that commit had no idea that bind already
automatically caches DNS responses, and, more importantly, that its caching
algorithms are a result of painful lessons learned from various DNS cache
poisoning attacks, that have circulated around the intertubes, for the last
couple of years.
The only possible use case for this kind of caching approach would be if:
A) You do not have a local DNS server nearby; and you have non-negligible
latencies to whatever DNS server you use.
B) Your queries tend to be for domains that your DNS servers are not
authoritative for, so they'll benefit from local caching.
So, can someone explain to me how likely this is going to be the case in a
typical deployment scenario that systemd is targeted for; in an average
corporate environment where systemd's alleged benefits will supposedly shine?
I would guess that a typical systemd deployment, in a corporate/business
environment, will certainly have multiple, low-latency DNS servers nearby,
won't that be the case? And, if so, then this is just another potentially
exploitable security hole in systemd, nothing more.
P.S. After I wrote the above, poking around, Google dumped this onto my
screen:
http://seclists.org/oss-sec/2014/q4/592
Mental note to myself: go back and check the timestamp of the systemd git
commit – before, or after, this was disclosed…
11:02 a.m.
On Tue, Dec 2, 2014 at 11:34 AM, Lars E. Pettersson <lars(a)homer.se> wrote:
On 12/02/14 15:47, Paul W. Frields wrote:
> Well, to be frank, it was sold to solve the issue of start up time of
>> computers.
>>
> ...
> This is incorrect. The actual problems systemd was meant to solve
> include but are not limited to:
>
No, it was sold to us, in the beginning, with the promise of faster boot
time. I remember the often long and winding discussions on whether this
materialized or not...
I unfortunately have to side with Lars (while also trying not to fuel the
fire)
Because of this he-said/she-said discussion,
I dug up and read this reference/announcement for systemd.
http://0pointer.de/blog/projects/systemd.html
And from what I quickly read, it focuses on 'parallel' startup
(which I can see no other reason for, other than speeding boot time)
but on the other hand, although it talks about 'logging everything',
it didn't advertize or mention the binary approach that we now have
that many object to.
3:40 p.m.
New subject: please stop this thread; constructive discussion can take place in a new one [was Re: Latest systemd news]
On 12/02/2014 06:23 AM, Matthew Miller wrote:
Let's stop this thread. New discussion about specific
functionality
actually intended to discuss, share, and learn rather than inflame is
fine, but since this *is* a topic which attracts all manner of strong
feelings, please take *extra* care in any such new thread.
thanx 10E6
--
Glenn Holmer (Linux registered user #16682)
"After the vintage season came the aftermath -- and Cenbe."
12:22 p.m.
On 12/02/2014 06:47 AM, Paul W. Frields wrote:
On Tue, Dec 02, 2014 at 09:40:53AM +0100, Lars E. Pettersson wrote:
> On 12/02/14 02:45, Rahul Sundaram wrote:
>> Well, it was originally meant to be default in Fedora 14 and there were
>> many discussions about it. it is been years since that point. Perhaps
>> people didn't pay attention to it and didn't realize it but it
wasn't
>> snuck in when people weren't looking. There were literally hundreds of
>> mails on the subject before it become default.
>
> Well, to be frank, it was sold to solve the issue of start up time of
> computers. It has then evolved to almost transfer the GNU/Linux concept to
> systemd/Linux. And this is something that has to be addressed, even on on a
> users list. Users use Fedora too, you know :) and might have usable (users)
> views on the subject.
This is incorrect. The actual problems systemd was meant to solve
include but are not limited to:
* Properly sorting dependencies of services
Well, they sure missed on that one. If anything, this has become a real
quagmire with systemd.
* Simplifying startup configuration
Simplifying startup? What an utter and complete misread. Startup is
INCREDIBLY more complex now. Over 6MB of config files in four or five
directories scattered all over hell and gone? They call that simplifying
startup configs? Really?
Just try to sort out a frozen boot sometime. You have NO idea what the
hell's going on because there are multiple processes running and
there's no way to tell what's locked up. On top of that, journalctl
stuffs everything useful into a bloody database so it's difficult to see
what's what. We used to be able to boot to single user mode and look
at the logs. Not anymore. Sheesh!
* Allowing arbitrary levels of startup
I might allow this, but was there really any need to do this? That's
what rc.local was for.
* Allowing sysadmins more control over resource utilization
I really fail to see how that's the case. If anything, this
parallelization crud uses MORE resources, not less.
The fact that the parallelization in systemd permits faster startup
time was a side benefit.
And a piss-poor benefit. If you're rebooting so often that this is a
problem, then you have other issues that need sorting before dealing
with this perceived bottleneck.
<soap>
I've said this before and I will continue to say it: systemd (and
journalctl's horrible abomination of stuffing logs into databases) are
solutions to problems that never existed. They are unnecessarily
complex, fraught with race conditions and dependency issues, resource
hogs, and just really, really stupid ideas in general. It appears that
the people who have forced these beasties on us are all ex-government
officials ("We know what's best for you...you're too stupid to deal
with it.")
</soap>
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital ricks(a)alldigital.com -
- AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 -
- -
- IGNORE that man behind the keyboard! -
- - The Wizard of OS -
----------------------------------------------------------------------
11:13 a.m.
On Tue, Dec 02, 2014 at 05:34:53PM +0100, Lars E. Pettersson wrote:
On 12/02/14 15:47, Paul W. Frields wrote:
>>Well, to be frank, it was sold to solve the issue of start up time of
>>computers.
...
>This is incorrect. The actual problems systemd was meant to solve
>include but are not limited to:
No, it was sold to us, in the beginning, with the promise of faster boot
time. I remember the often long and winding discussions on whether this
materialized or not...
I think "promise" is not correct here either. "Potential" perhaps.
As Lennart's original blog shows, the driving requirements were better
parallelization and on-demand startup, responsiveness to dynamic
system change, socket activation, better process tracking, execution
environment control, and improved event logic. Speed of boot time was
not guaranteed but a likely outcome for some hardware configurations
(not all, which would be silly to promise, and impossible to provide).
You can read it for yourself here:
http://0pointer.de/blog/projects/systemd.html
The blog of course mentions speed, because that's what many people
were discussing at the time, but it correctly places this in the
context of what is desirable, rather than what is required. An init
system with the proper requirements would likely yield the speed some
people were looking for, but the purpose of systemd is not simply to
be fast.
--
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
The open source story continues to grow: http://opensource.com
10:34 a.m.
On 12/02/14 15:47, Paul W. Frields wrote:
> Well, to be frank, it was sold to solve the issue of start up
time of
> computers.
...
This is incorrect. The actual problems systemd was meant to solve
include but are not limited to:
No, it was sold to us, in the beginning, with the promise of faster boot
time. I remember the often long and winding discussions on whether this
materialized or not...
Lars
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
8:52 a.m.
New subject: please stop this thread; constructive discussion can take place in a new one [was Re: Latest systemd news]
On 12/02/14 13:23, Matthew Miller wrote:
> But what happens when they are ready? Will they be part of Fedora
then?
Lars, we have a change control process for precisely this reason. The
systemd developers and packagers in Fedora are (mostly) conscientious
about going through it.
My comment and cited question above has been taken somewhat out of
context here. I am not debating the change control process etc. Just
stating that new features in systemd have a tendency to find its way
into the standard Fedora release (sooner or later), and that the new
feature discussed earlier in the thread most likely will be handled in
the same manner. And that this fact makes a discussion about this new
feature on-topic for this list. And not off-topic as Rahul states.That
is all...
Lars
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
8:47 a.m.
On Tue, Dec 02, 2014 at 09:40:53AM +0100, Lars E. Pettersson wrote:
On 12/02/14 02:45, Rahul Sundaram wrote:
>Well, it was originally meant to be default in Fedora 14 and there were
>many discussions about it. it is been years since that point. Perhaps
>people didn't pay attention to it and didn't realize it but it wasn't
>snuck in when people weren't looking. There were literally hundreds of
>mails on the subject before it become default.
Well, to be frank, it was sold to solve the issue of start up time of
computers. It has then evolved to almost transfer the GNU/Linux concept to
systemd/Linux. And this is something that has to be addressed, even on on a
users list. Users use Fedora too, you know :) and might have usable (users)
views on the subject.
This is incorrect. The actual problems systemd was meant to solve
include but are not limited to:
* Properly sorting dependencies of services
* Simplifying startup configuration
* Allowing arbitrary levels of startup
* Allowing sysadmins more control over resource utilization
The fact that the parallelization in systemd permits faster startup
time was a side benefit.
--
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
The open source story continues to grow: http://opensource.com
8:40 a.m.
New subject: Better tools needed - Re: Latest systemd news
Hi
On Tue, Dec 2, 2014 at 6:09 AM, Robert Moskowitz wrote:
> systemctl list-unit-files
>
Lists 315 services, most that I can't control. And does it no longer
matter if you are in single user, multiuser, etc mode on how the services
run?
As I pointed out before, you *can* control them. There are no modes or
runlevels in systemd. The functional equivalent is a target.
https://fedoraproject.org/wiki/Systemd#How_do_I_change_the_target_.28runl...
If you want to have a limited view of just services, then systemctl
list-units -t service or --type=service. That lists about 75 services in
my laptop.
Rahul
8:38 a.m.
On 12/02/14 15:25, Rahul Sundaram wrote:
Users list
is for discussing features that are shipped in Fedora general release.
systemd IS a part of Fedora general release.
>Well, to be frank, it was sold to solve the issue of start up
time of
computer
To be frank, it was never sold as only a solution for that.
It was, in the beginning. It then started to take over more and more
other functions.
Lars
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
8:25 a.m.
Hi
On Tue, Dec 2, 2014 at 3:19 AM, Lars E. Pettersson wrote:
The discussion is about a component already in use in Fedora,
systemd,
and new features of it. How can this not be on-topic here?
You keep asking the same question that was answered before. Users list is
for discussing features that are shipped in Fedora general release. Not
for things not included in Fedora or only included in Rawhide or test
releases. I guess instead of pretending that this question was unanswered,
we are going to just disagree.
Well, to be frank, it was sold to solve the issue of start up time of
computer
To be frank, it was never sold as only a solution for that.
Rahul
6:23 a.m.
New subject: please stop this thread; constructive discussion can take place in a new one [was Re: Latest systemd news]
On Mon, Dec 01, 2014 at 09:15:45PM +0100, Lars E. Pettersson wrote:
Well, if they are not yet ready or not general purpose enough to be
used by default they should not be adopted. We have enough of not
yet ready products and does not need any more.
But what happens when they are ready? Will they be part of Fedora then?
Lars, we have a change control process for precisely this reason. The
systemd developers and packagers in Fedora are (mostly) conscientious
about going through it.
I have been on the RedHat/Fedora lists since about 1996 and seen the
So, you should know this.
Rahul, precisely where in the guidelines does it say that it is, on
this list, prohibited to discuss new functionality in a package used
by Fedora, functionality that with huge probability will make into
Fedora? And if it is prohibited here, where should it be discussed
(out of the Fedora mailing lists)?
Discussing it in a useful way is fine. Waking up this troll thread
(and, it _was_ a troll thread -- there's really no question!) with
general unease does not seem constructive either.
Let's stop this thread. New discussion about specific functionality
actually intended to discuss, share, and learn rather than inflame is
fine, but since this *is* a topic which attracts all manner of strong
feelings, please take *extra* care in any such new thread.
Thanks.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
6:14 a.m.
On Mon, Dec 01, 2014 at 07:00:39PM -0500, Rahul Sundaram wrote:
> "community assistance, encouragement, and advice" —
not to mention the
> Friends foundation — that's a different story.
I would suggest that the thread is off the rails long time back and not
enforcing the list guidelines and keeping the list on topic leads to us,
It started with an objectively silly and inflammatory post but had
mostly died down on its own. *sigh*
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
2:34 a.m.
On 12/02/14 01:00, Rahul Sundaram wrote:
I would suggest that the thread is off the rails long time back and
not
enforcing the list guidelines and keeping the list on topic leads to us,
No, it is not "Off the rails". That you find the issue unimportant does
not mean that others have the same view. It is also quite easy to ignore
threads on subjects that you have no interest in, that could be a
solution for those not interested in the subject of this thread. The
discussion is about a component already in use in Fedora, systemd, and
new features of it. How can this not be on-topic here?
Lars
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
2:19 a.m.
On 12/01/14 22:32, Rahul Sundaram wrote:
By that account why would rawhide or test releases be considered
offtopic? How about development kernel or glibc features?
The test list is about test releases of Fedora. The devel list is for
the development releases of Fedora (rawhide). All as I mentioned before...
>But I can not see that discussing Fedora users view on new
features of
systemd on the systemd mailing lists will lead to any good...
Why wouldn't it?
That list is specific for systemd, not Fedora and the Fedora users view
on systemd.
Lars
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
2:11 a.m.
On 1 December 2014 at 16:27, Rahul Sundaram <metherid(a)gmail.com> wrote:
Hi
On Mon, Dec 1, 2014 at 10:49 AM, Lars E. Pettersson wrote:
>
> My question was "What part(s) of the systemd suite has not been adopted".
> Note the not part.
Yes. I understood that fine. I was pointing out which parts have been
adopted so you can count the rest as not adopted. There are several
different components which haven't been adopted nor even proposed because
they are simply not yet ready or not general purpose enough to be used by
default.
>>
>> when they are actually proposed, a discussion about them would be
>> warranted.
>
>
> I.e. it might very well be adopted and therefor a discussion about it is
> in order. Why wait for the inevitable?
That makes no sense. You don't discuss developmental features of upstream
projects in a users list.
>
>
> This is not about a test or development release. It is about new
> functionality finding its way into systemd
Precisely why it is even more offtopic to discuss them here. This list is
meant for helping users on general releases of Fedora. Any features that are
not part of the general releases of Fedora is not suitable for discussion
here. We wrote up the list guidelines for a reason. Please follow them.
Where should users be discussing things that may negatively impact
them? On the systemd list they will get shouted down by systemd
cheerleaders, on the devel list they will get told the decision has
already been made and they should go to the systemd list.
--
imalone
http://ibmalone.blogspot.co.uk
8:14 p.m.
Just to point out how explosive the systemd issue is in the Linux
community, note that Debian has been forked just beause of this:
https://lists.dyne.org/lurker/message/20141127.212941.f55acc3a.en.html
Yes, I know, this isn't Fedora. But if it's that controversial that an
enire distro will split, we can't ignore the issue for Fedora and,
eventually (or already), Redhat.
Sincerely,
--
Dave Ihnat
dihnat(a)dminet.com
8:12 p.m.
Hi
On Mon, Dec 1, 2014 at 9:01 PM, Dave Ihnat wrote:
That is intensely needed. I think either new material explaining exactly
why systemd is needed, and good, is critical. If it already exists,
collected pointers are just as good (if not better)
There are dozens of references about half way from
http://freedesktop.org/wiki/Software/systemd/
Also
https://fedoraproject.org/wiki/Systemd
https://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet
systemd also also an extensive amount of man pages.
Rahul
8:01 p.m.
On Mon, Dec 01, 2014 at 08:45:28PM -0500, Rahul Sundaram wrote:
Well, it was originally meant to be default in Fedora 14 and there
were
many discussions about it. it is been years since that point. Perhaps
people didn't pay attention to it and didn't realize it but it wasn't snuck
in when people weren't looking. There were literally hundreds of mails on
the subject before it become default.
There will always be new participants, and we all know the Linux crowd can
be...volatile...when they're surprised. Yes, it may not be right that
they're surprised, if there was a lot of discussion, but that is the
reality. Some people don't pay attention, some are new since the
discussion, etc. Normally, this wouldn't matter. But systemd is not
normal.
I don't mind the feedback at all. In fact, if it was more
useful, I would
spend *more* of my volunteer time on it and be more effective at it.
I thorougly appreciate your time and effort. I've been in the volunteer
arena numerous times; every time, it's ended in exhaustion, firm decision
never again--and then I'm back. Volunteer organizations will use you and
drain you; for some reason, we always come back. It's probably some sort
of addiction.
For my part, I have been trying to improve the quality of the
documentation
including the wiki and man pages.
That is intensely needed. I think either new material explaining exactly
why systemd is needed, and good, is critical. If it already exists,
collected pointers are just as good (if not better).
Sincerely,
--
Dave Ihnat
dihnat(a)dminet.com
7:45 p.m.
Hi
On Mon, Dec 1, 2014 at 8:31 PM, Dave Ihnat wrote:
I agree, but I will point out that incorporating systemd is an...extremely
controversial...decision. And, the entire arena seems to be fraught with
extreme opinions. Couple that with the fact that many here seem not to
have known it was coming, and the excitement is predictable.
Well, it was originally meant to be default in Fedora 14 and there were
many discussions about it. it is been years since that point. Perhaps
people didn't pay attention to it and didn't realize it but it wasn't snuck
in when people weren't looking. There were literally hundreds of mails on
the subject before it become default.
I don't mind the feedback at all. In fact, if it was more useful, I would
spend *more* of my volunteer time on it and be more effective at it. For
my part, I have been trying to improve the quality of the documentation
including the wiki and man pages.
Rahul
7:37 p.m.
New subject: Better tools needed - Re: Latest systemd news
HI
On Mon, Dec 1, 2014 at 8:31 PM, Robert Moskowitz wrote:
And the list is hugh compared to what services are really up to user
control. I mean listed items like:
Yes that list is larger because systemd does allow you to control more than
sysvinit does directly. Try it out
Oh, and that (perferred) gives an error :)
I am not sure if you actually typed in preferred. I have clarified the
note anyway in the wiki.
Rahul
7:31 p.m.
On Mon, Dec 01, 2014 at 08:19:47PM -0500, Rahul Sundaram wrote:
Sure. I wasn't referring to your post. Your effort is
appreciated.
Ah; thank you. I really am tired of drama, and try not to contribute.
I don't disagree with all that. I do disagree that the current
approach
taken in the beginning of the thread does a good job of doing that.
I agree, but I will point out that incorporating systemd is an...extremely
controversial...decision. And, the entire arena seems to be fraught with
extreme opinions. Couple that with the fact that many here seem not to
have known it was coming, and the excitement is predictable. Perhaps
regrettable, but still, this is the venue we need to address--it's the
precursor to what Redhat will run into as it rolls this out to the
industry.
Red Hat and other Fedora Project volunteer contributors should take
feedback
from this list seriously and for this to happen, all participants need to
work better on providing feedback in a form that is useful. That is a
collective responsibility and one that I find important.
Thoroughly agree. Think twice, post once.
Sincerely,
--
Dave Ihnat
dihnat(a)dminet.com
7:31 p.m.
New subject: Better tools needed - Re: Latest systemd news
On 12/01/2014 08:23 PM, Rahul Sundaram wrote:
HI
On Mon, Dec 1, 2014 at 8:17 PM, Robert Moskowitz wrote:
Perhaps at some point we will get better tools for using systemd.
Thanks for bringing in something useful to the discussion that I can
address:
I mean compare:
systemctl restart sshd.service
with
service sshd restart
Is there something else to do with sshd other than sshd.service?
I have not found it. Why not:
systemctl restart sshd
Have you tried? Hint: It works fine.
Nope. Nice to know.
Then there was good old 'chkconfig' that produced a nice
tablular
report of services that can be controlled. I have yet to find
anything close to this with systemd.
https://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet
You think
'chkconfig --list' can be easily replaced with
systemctl list-unit-files --type=service(preferred)
ls /etc/systemd/system/*.wants/
Nah. No way.
Oh, and that (perferred) gives an error :)
And the list is hugh compared to what services are really up to user
control. I mean listed items like:
dbus-org.fedoraproject.FirewallD1.service enabled
dbus-org.freedesktop.hostname1.service static
dbus-org.freedesktop.locale1.service static
dbus-org.freedesktop.login1.service static
dbus-org.freedesktop.machine1.service static
dbus-org.freedesktop.ModemManager1.service enabled
dbus-org.freedesktop.NetworkManager.service enabled
dbus-org.freedesktop.nm-dispatcher.service enabled
dbus-org.freedesktop.timedate1.service static
dbus.service static
And there are others there that are just as challenging to remember when
you need them.
7:23 p.m.
New subject: Better tools needed - Re: Latest systemd news
HI
On Mon, Dec 1, 2014 at 8:17 PM, Robert Moskowitz wrote:
Perhaps at some point we will get better tools for using systemd.
Thanks for bringing in something useful to the discussion that I can
address:
I mean compare:
systemctl restart sshd.service
with
service sshd restart
Is there something else to do with sshd other than sshd.service? I have
not found it. Why not:
systemctl restart sshd
Have you tried? Hint: It works fine.
Then there was good old 'chkconfig' that produced a nice
tablular report
of services that can be controlled. I have yet to find anything close to
this with systemd.
https://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet
Rahul
7:17 p.m.
New subject: Better tools needed - Re: Latest systemd news
On 12/01/2014 07:23 PM, Dave Ihnat wrote:
On Mon, Dec 01, 2014 at 07:00:39PM -0500, Rahul Sundaram wrote:
> I would suggest that the thread is off the rails long time back and not
> enforcing the list guidelines and keeping the list on topic leads to us,
> unable to point our own users to the list for help because they have to
> wade through rants.
With all due respect, it's very clear to me that systemd is a game changer
and has invoked very intense and concerned responses from the entire Linux
community.
It's not sensible to just say "not here". Fedora is supposed to be a
testing ground for future Redhat releases; as such, its community is--or
should be--a valuable "canary" for response from Redhat end users in the
future. That there is so much concern about systemd tells me there is a
problem--whether technical, or perceptual--that should be resolved *here*,
not in the Redhat release channels. Resolution here can be used by Redhat
in their commercial venue.
Again, with all due respect, my suggestion is to convince Fedora users that
the decision to migrate to systemd is a good idea. They're your advocates
and concept testers. Just telling them to "shut up, out of scope" seems a
bad idea.
Perhaps at some point we will get better tools for using systemd. I
mean compare:
systemctl restart sshd.service
with
service sshd restart
Is there something else to do with sshd other than sshd.service? I have
not found it. Why not:
systemctl restart sshd
The 'd' at the end of the name has always implied service. This is the
default mode. Perhaps there is more, but those that work with 'more'
will tend to know 'more'.
Then there was good old 'chkconfig' that produced a nice tablular report
of services that can be controlled. I have yet to find anything close
to this with systemd.
Perhaps much of the complaining and doom and gloom is that systemV was
'easy' to work with where as systemd is presented as too rich of an
environment to interact with.
7:08 p.m.
On Mon, Dec 01, 2014 at 07:55:51PM -0500, Rahul Sundaram wrote:
Good thing nobody did that then, right?
Well, that's good.
With all due respect, you can't argue against your own made up
quote.
(Hands up), no arguing.
Ranting about ...
Excuse me; I worked very hard to *not* rant. It intended to be, and I
believe was, a reasoned and rational attempt to explain why someone would
be asking questions about systemd and the decisions, current and projected,
to incorporate it into Fedora. And to express the belief that this forum,
and its participants, are important to Redhat's decison making process, and
why.
Sincerely,
--
Dave Ihnat
dihnat(a)dminet.com
6:23 p.m.
On Mon, Dec 01, 2014 at 07:00:39PM -0500, Rahul Sundaram wrote:
I would suggest that the thread is off the rails long time back and
not
enforcing the list guidelines and keeping the list on topic leads to us,
unable to point our own users to the list for help because they have to
wade through rants.
With all due respect, it's very clear to me that systemd is a game changer
and has invoked very intense and concerned responses from the entire Linux
community.
It's not sensible to just say "not here". Fedora is supposed to be a
testing ground for future Redhat releases; as such, its community is--or
should be--a valuable "canary" for response from Redhat end users in the
future. That there is so much concern about systemd tells me there is a
problem--whether technical, or perceptual--that should be resolved *here*,
not in the Redhat release channels. Resolution here can be used by Redhat
in their commercial venue.
Again, with all due respect, my suggestion is to convince Fedora users that
the decision to migrate to systemd is a good idea. They're your advocates
and concept testers. Just telling them to "shut up, out of scope" seems a
bad idea.
Sincerely,
--
Dave Ihnat
dihnat(a)dminet.com
3:04 p.m.
On 12/01/14 21:47, Rahul Sundaram wrote:
I will limit my answer to one point to keep it brief. Despite your
insistence, development features that are part of upstream project but
not in any Fedora release *cannot* affect Fedora users by definition
Hence they are offtopic for this list. If you want to discuss them,
go to the upstream project mailing list for that
As systemd is (a huge) part of Fedora, and what we discuss is a new
feature in systemd, it will, eventually, affect the users of Fedora. It
is therefore, by definition, a users issue. A users issue that is very
much on-topic on this users list.
Lars
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
2:47 p.m.
Hi
On Mon, Dec 1, 2014 at 3:15 PM, Lars E. Pettersson wrote:
The issue being discussed in this thread has nothing to do with test
releases and has because of that nothing to do on the test list. It has
nothing to do with the development releases (rawhide) and has because of
that nothing to do on the fedora-devel list. But again, this will affect
the users of Fedora, and this list is about the users of Fedora
I will limit my answer to one point to keep it brief. Despite your
insistence, development features that are part of upstream project but not
in any Fedora release *cannot* affect Fedora users by definition Hence
they are offtopic for this list. If you want to discuss them, go to the
upstream project mailing list for that
Rahul
2:15 p.m.
On 12/01/14 17:27, Rahul Sundaram wrote:
There are several
different components which haven't been adopted nor even proposed
because they are simply not yet ready or not general purpose enough to
be used by default.
Well, if they are not yet ready or not general purpose enough to be used
by default they should not be adopted. We have enough of not yet ready
products and does not need any more.
But what happens when they are ready? Will they be part of Fedora then?
What ready parts, or what not general purpose enough parts of systemd
has not been adopted by Fedora? That is what I am pointing at. With the
meaning that what we discuss in this thread with huge probability will
make it into Fedora when it is ready, just as the rest of the systemd suite.
I.e. it might very well be adopted and therefor a discussion
about
it is in order. Why wait for the inevitable?
That makes no sense. You don't discuss developmental features of
upstream projects in a users list.
It makes perfect sense. It will with huge probability make it into
Fedora and because of that it will affect the users of Fedora who
thereby have all the rights to discuss this user issues on the users
list. Even at this early stage.
This is not about a test or development release. It is about new
functionality finding its way into systemd
Precisely why it is even more offtopic to discuss them here. This list
is meant for helping users on general releases of Fedora. Any features
that are not part of the general releases of Fedora is not suitable for
discussion here. We wrote up the list guidelines for a reason. Please
follow them.
I have been on the RedHat/Fedora lists since about 1996 and seen the
progress of the different list and (endless?) discussions about what to
discuss and what not to discuss. And judging from that experience, I see
no harm whatsoever in discussing new functionality that (eventually)
will make it into Fedora default and thereby affect the users of Fedora.
The issue being discussed in this thread has nothing to do with test
releases and has because of that nothing to do on the test list. It has
nothing to do with the development releases (rawhide) and has because of
that nothing to do on the fedora-devel list. But again, this will affect
the users of Fedora, and this list is about the users of Fedora.
Rahul, precisely where in the guidelines does it say that it is, on this
list, prohibited to discuss new functionality in a package used by
Fedora, functionality that with huge probability will make into Fedora?
And if it is prohibited here, where should it be discussed (out of the
Fedora mailing lists)?
Lars
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
10:27 a.m.
Hi
On Mon, Dec 1, 2014 at 10:49 AM, Lars E. Pettersson wrote:
My question was "What part(s) of the systemd suite has not been
adopted".
Note the not part.
Yes. I understood that fine. I was pointing out which parts have been
adopted so you can count the rest as not adopted. There are several
different components which haven't been adopted nor even proposed because
they are simply not yet ready or not general purpose enough to be used by
default.
when they are actually proposed, a discussion about them would be
> warranted.
>
I.e. it might very well be adopted and therefor a discussion about it is
in order. Why wait for the inevitable?
That makes no sense. You don't discuss developmental features of upstream
projects in a users list.
This is not about a test or development release. It is about new
functionality finding its way into systemd
Precisely why it is even more offtopic to discuss them here. This list is
meant for helping users on general releases of Fedora. Any features that
are not part of the general releases of Fedora is not suitable for
discussion here. We wrote up the list guidelines for a reason. Please
follow them.
Rahul
4:33 a.m.
On 12/01/14 02:31, Rahul Sundaram wrote:
Hi
On Sun, Nov 30, 2014 at 2:48 PM, Lars E. Pettersson wrote:
On 11/18/14 04:20, Rahul Sundaram wrote:
user mailing list of a distribution which doesn't even use the
component
at all yet.
Well, how long do you think it will take until the "component" is
being used then? Systemd have had a tendency to very quickly find
its way into Fedora, and probably this will also do so. I.e., it
might not be here yet, but it is on the door step. And discussions
about this is a good thing, even on this list.
No. It isn't. Not unless the component is proposed.
What part(s) of the systemd suite has not been adopted by Fedora so far?
What says that this "component" will not be adopted by fedora?
If you going to
rant about some experimental component a few days after it has been
committed to the master repository, please do it elsewhere.
Why? Where? Why shouldn't users be allowed to discuss these things here?
Lars
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
7:31 p.m.
Hi
On Sun, Nov 30, 2014 at 2:48 PM, Lars E. Pettersson wrote:
On 11/18/14 04:20, Rahul Sundaram wrote:
> user mailing list of a distribution which doesn't even use the component
> at all yet.
>
Well, how long do you think it will take until the "component" is being
used then? Systemd have had a tendency to very quickly find its way into
Fedora, and probably this will also do so. I.e., it might not be here yet,
but it is on the door step. And discussions about this is a good thing,
even on this list.
No. It isn't. Not unless the component is proposed. If you going to rant
about some experimental component a few days after it has been committed to
the master repository, please do it elsewhere.
Rahul
9:20 p.m.
Hi
On Mon, Nov 17, 2014 at 9:35 PM, Sam Varshavchik wrote:
Right. Like "systemd developers" have such an established
track record of
listening to feedback from the community,
That has no connection to what I said. If you have already made up your
mind, that's fine but if you are wondering why it is implemented, the right
place to direct the question is to the developers and not in a user mailing
list of a distribution which doesn't even use the component at all yet.
Rahul
8:35 p.m.
Rahul Sundaram writes:
Hi
On Mon, Nov 17, 2014 at 5:09 PM, Chris Adams wrote:
Why did the systemd
project add this to the scope of the project for "a system and service
manager for Linux"?
This was something that could have been easily asked to systemd developers
rather than the long rant that was posted. In any case,
Right. Like "systemd developers" have such an established track record of
listening to feedback from the community, and the DNS cache was implemented
only pursuant to an open, lengthy discussion on the merits and disadvantages
of it.
Er… I don't think so.
The scenario outlined there would be a valid argument for a simple DNS
proxy, and nothing more. I could see this being a perfectly reasonable, and
prudent, argument for a simple DNS proxy, that all containers get pointed
to, and which forwards the DNS queries to whatever the current outside DNS
server the host is configured for, at the moment.
That makes perfect sense. A cobbled-together DNS cache, on the other hand,
makes no sense, whatsoever. Reports of a compromised container poisoning the
systemd DNS cache, and uses that to attack other containers on the same
systems, in 3… 2… 1…
This is really nothing more than a NIH syndrome. Really, that's all this is.
8:26 p.m.
On 11/17/2014 06:54 PM, Rahul Sundaram wrote:
Hi
On Mon, Nov 17, 2014 at 5:09 PM, Chris Adamswrote:
Why did the systemd
project add this to the scope of the project for "a system and service
manager for Linux"?
This was something that could have been easily asked to systemd
developers rather than the long rant that was posted. In any case,
https://lwn.net/Articles/621201/
Also CoreOS sponsored development of a lot of network stack. You can
refer to their guides on how they are using it.
"already from the basic design resolved is very different from unbound.
resolved keeps a seperate "scope" for the DNS servers on each interface.
A "scope" is a resolver state machine plus a cache. That way, we can
neatly separate VPN DNS servers from internet DNS servers, and merge
them transparently. That means that with resolved in the mix for the
first time you don't lose access to your LAN's DNS names, fully
automatically, without any manual hacks. Also, as interfaces come and go
their caches do too with this scheme, hence all the cache flushing
complexity of dnssec-trigger doesn't exist at all. Then, because we
actually implement LLMNR and DNS int he same stack (as well as mDNS very
soon), we can transparently merge those protocols too."
For those of us that deal with VPNs, we know how hard split horizon is,
and actually how important it is for good performance. It is almost a
shame it took until now for someone to address DNS by Interface.
Actually it coincides with work in IETF on such matters.
5:54 p.m.
Hi
On Mon, Nov 17, 2014 at 5:09 PM, Chris Adams wrote:
Why did the systemd
project add this to the scope of the project for "a system and service
manager for Linux"?
This was something that could have been easily asked to systemd developers
rather than the long rant that was posted. In any case,
https://lwn.net/Articles/621201/
Also CoreOS sponsored development of a lot of network stack. You can refer
to their guides on how they are using it.
Rahul
5:04 p.m.
On Mon, Nov 17, 2014 at 5:09 PM, Chris Adams <linux(a)cmadams.net> wrote:
Once upon a time, Juan Orti <juan.orti(a)miceliux.com> said:
> systemd-resolved is a daemon for resolving DNS. What's wrong about
> caching? All DNS servers perform caching.
>
> It's like if you have unbound at 127.0.0.1 as local resolver, that's a
> very common setup.
Well, that's the point. We already have multiple, perfectly functional,
caching resolvers. We have resolver libraries. Why did the systemd
project add this to the scope of the project for "a system and service
manager for Linux"? Why didn't they re-use existing services and/or
libraries? Why re-invent a wheel that happens to have a number of
corner cases that can be tricky to get right (and a security problem if
you get it wrong)?
In general DNS caching may be useful, but with other perfectly good
solution(s) (i.e. nscd) for Linux the implementation of the same in systemd
does not add value.
4:02 p.m.
El sáb, 15-11-2014 a las 08:53 -0500, Sam Varshavchik escribió:
Making the rounds of various technical mailing lists yesterday, with
a
subject that's typically a variation of "Just for yucks, and giggles" is a
link to a commit to systemd's git, adding DNS caching to systemd; in one,
huge 857 line glop. Here's its entire commit message: "resolved: add DNS
cache".
systemd-resolved is a daemon for resolving DNS. What's wrong about
caching? All DNS servers perform caching.
It's like if you have unbound at 127.0.0.1 as local resolver, that's a
very common setup.
4:09 p.m.
Once upon a time, Juan Orti <juan.orti(a)miceliux.com> said:
systemd-resolved is a daemon for resolving DNS. What's wrong
about
caching? All DNS servers perform caching.
It's like if you have unbound at 127.0.0.1 as local resolver, that's a
very common setup.
Well, that's the point. We already have multiple, perfectly functional,
caching resolvers. We have resolver libraries. Why did the systemd
project add this to the scope of the project for "a system and service
manager for Linux"? Why didn't they re-use existing services and/or
libraries? Why re-invent a wheel that happens to have a number of
corner cases that can be tricky to get right (and a security problem if
you get it wrong)?
--
Chris Adams <linux(a)cmadams.net>
10:18 a.m.
Once upon a time, Sam Varshavchik <mrsam(a)courier-mta.com> said:
Making the rounds of various technical mailing lists yesterday, with
a subject that's typically a variation of "Just for yucks, and
giggles" is a link to a commit to systemd's git, adding DNS caching
to systemd; in one, huge 857 line glop. Here's its entire commit
message: "resolved: add DNS cache".
Yet more unreasonable scope creep for the systemd project, and this time
reinventing the wheel for no good reason. There are already perfectly
good resolver libraries, caches, etc.; there is no good reason for
systemd to grow its own.
--
Chris Adams <linux(a)cmadams.net>
10:49 a.m.
On Sat, Nov 15, 2014 at 08:53:59AM -0500, Sam Varshavchik wrote:
Making the rounds of various technical mailing lists yesterday, with
a subject that's typically a variation of "Just for yucks, and
giggles" is a link to a commit to systemd's git, adding DNS caching
to systemd; in one, huge 857 line glop. Here's its entire commit
message: "resolved: add DNS cache".
This would be funny if it wasn't real. Seriously, if we'd described
systemd to ourselves 10 years ago, we'd think it was parody.
I never, ever liked watching train wrecks. And never thought it a good
idea to let the inmates run the asylum.
--
Dave Ihnat
dihnat(a)dminet.com
11:09 a.m.
On Nov 15, 2014 6:54 AM, "Sam Varshavchik" <mrsam(a)courier-mta.com> wrote:
Making the rounds of various technical mailing lists yesterday, with a
subject
that's typically a variation of "Just for yucks, and giggles" is a
link to a commit to systemd's git, adding DNS caching to systemd; in one,
huge 857 line glop. Here's its entire commit message: "resolved: add DNS
cache".
And, it's beauty to read. Made me teary-eyed to know that systemd will
cache my
DNS queries. Not sure why systemd, all of a sudden, needs to make
DNS queries. But if it does, it's going to cache them now! Such a sight to
behold makes my heart skip a beat: now, not just bind, or pretty much every
DNS server that automatically caches DNS for you – but so will systemd!
But, seriously folks, systemd's DNS caching achieves absolutely 100%
nothing.
Really. Surprised? Well, you'll be shocked to know that the DNS
server that systemd queries for that DNS RR, such as the stock "bind",
already automatically caches all recursive DNS replies!! systemd's own
caching produces absolutely zero useful results. On the oft chance that it
sends a query for a non-cached RR, the local DNS server will cache the
response, before returning it to systemd, and then use the cached response
for all future queries. That's what DNS servers do: provide caching for
local clients. It's inherent in DNS's design: DNS was explicitly designed
to use aggressive caching, it's an internet-wide, distributed, locally
cached database.
Isn't modern technology amazing?
I'm willing to consider the possibility that I missed something obvious,
some
obvious value-added result from caching DNS RRs directly by systemd,
and I'll stick around for someone to enlighten me; or if Occam's razor
applies, and the author of that commit had no idea that bind already
automatically caches DNS responses, and, more importantly, that its caching
algorithms are a result of painful lessons learned from various DNS cache
poisoning attacks, that have circulated around the intertubes, for the last
couple of years.
The only possible use case for this kind of caching approach would be if:
A) You do not have a local DNS server nearby; and you have non-negligible
latencies
to whatever DNS server you use.
B) Your queries tend to be for domains that your DNS servers are not
authoritative
for, so they'll benefit from local caching.
So, can someone explain to me how likely this is going to be the case in
a typical
deployment scenario that systemd is targeted for; in an average
corporate environment where systemd's alleged benefits will supposedly
shine?
I would guess that a typical systemd deployment, in a corporate/business
environment, will certainly have multiple, low-latency DNS servers nearby,
won't that be the case? And, if so, then this is just another potentially
exploitable security hole in systemd, nothing more.
P.S. After I wrote the above, poking around, Google dumped this onto my
screen:
http://seclists.org/oss-sec/2014/q4/592
Mental note to myself: go back and check the timestamp of the systemd git
commit –
before, or after, this was disclosed…
--
I haven't read into it much yet, but the vast majority of systemd network
functionality is intended almost exclusively to support networking in
systemd-nspawn containers. The init system's job is to isolate and manage
services; container management is a logical add.
Whatever the intent, I hope that everyone discovers it from reading actual
documentation instead of inflammatory comments on indignant speculation
about the intent behind a one sentence feature description like "
resolved: add DNS cache ". I'm not necessarily putting you in that box,
Sam, but these discussions tend to feed on themselves and it makes
productive discourse difficult.
--Pete
3:13 p.m.
Hi
On Mon, Dec 1, 2014 at 4:04 PM, Lars E. Pettersson wrote:
As systemd is (a huge) part of Fedora, and what we discuss is a new
feature in systemd, it will, eventually,
That is by no means a good assumption but even if you take that assumption
as a given, it is not a good justification. This is exactly why I provided
the analogy of development releases of Fedora. What is in a test or
development release of Fedora will become part of Fedora regular releases
typically but even then, it is a good reason to discuss developmental
releases of Fedora in this list. There is a separate mailing list for
that. You are supposed to use that list instead. In a similar way,
development branches of systemd has its own mailing list for discussing
such functionality called systemd-devel list. Use that list if you are so
keen on discussing development branches of systemd.
Rahul
6:55 p.m.
Hi
On Mon, Dec 1, 2014 at 7:23 PM, Dave Ihnat wrote:
Just telling them to "shut up, out of scope" seems a
bad idea.
Good thing nobody did that then, right? With all due respect, you can't
argue against your own made up quote. As to the question of response from
Red Hat, in case you haven't noticed, RHEL 7 already has shipped with
it. Ranting about developmental features in systemd in a *users* list is
hardly a good way to provide feedback to either Fedora or Red Hat.
Rahul
7:19 p.m.
Hi
On Mon, Dec 1, 2014 at 8:08 PM, Dave Ihnat wrote:
> Ranting about ...
Excuse me; I worked very hard to *not* rant.
Sure. I wasn't referring to your post. Your effort is appreciated.
It intended to be, and I
believe was, a reasoned and rational attempt to explain why someone would
be asking questions about systemd and the decisions, current and projected,
to incorporate it into Fedora. And to express the belief that this forum,
and its participants, are important to Redhat's decison making process, and
why.
I don't disagree with all that. I do disagree that the current approach
taken in the beginning of the thread does a good job of doing that. Red
Hat and other Fedora Project volunteer contributors should take feedback
from this list seriously and for this to happen, all participants need to
work better on providing feedback in a form that is useful. That is a
collective responsibility and one that I find important.
Rahul
5:09 a.m.
New subject: Better tools needed - Re: Latest systemd news
On 12/02/2014 12:42 AM, Joe Zeff wrote:
On 12/01/2014 05:17 PM, Robert Moskowitz wrote:
>
> Then there was good old 'chkconfig' that produced a nice tablular report
> of services that can be controlled. I have yet to find anything close
> to this with systemd.
systemctl list-unit-files
Lists 315 services, most that I can't control. And does it no longer
matter if you are in single user, multiuser, etc mode on how the
services run?
2:40 a.m.
On 12/02/14 02:45, Rahul Sundaram wrote:
Well, it was originally meant to be default in Fedora 14 and there
were
many discussions about it. it is been years since that point. Perhaps
people didn't pay attention to it and didn't realize it but it wasn't
snuck in when people weren't looking. There were literally hundreds of
mails on the subject before it become default.
Well, to be frank, it was sold to solve the issue of start up time of
computers. It has then evolved to almost transfer the GNU/Linux concept
to systemd/Linux. And this is something that has to be addressed, even
on on a users list. Users use Fedora too, you know :) and might have
usable (users) views on the subject.
Lars
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
8:42 a.m.
Hi
On Tue, Dec 2, 2014 at 9:38 AM, Lars E. Pettersson wrote:
systemd IS a part of Fedora general release.
Yes but not the feature that was being discussed.
It was, in the beginning. It then started to take over more and more
other
functions.
Not true. It was never sold as only about fast startup. fast startup was
a side benefit.
Rahul
3:56 p.m.
On Mon, Dec 01, 2014 at 04:32:49PM -0500, Rahul Sundaram wrote:
> I am keen on discussing how new features in systemd (or any
other
> packages used by Fedora for that matter) will affect the users of
> Fedora. The best place for that is this users list.
By that account why would rawhide or test releases be considered
offtopic? How about development kernel or glibc features?
Honestly, I don't think constructive, on-topic discussion of those
things is too far off-topic. Discussion of actual development or
test releases, sure, but I don't think it'd be bad for someone to talk
about, for example, how OverlayFS might be used in Fedora.
If the thread goes off the rails and outside of the scope of
"community assistance, encouragement, and advice" — not to mention the
Friends foundation — that's a different story.
And in any case, a big back and forth about what is or isn't on topic
isn't helping anyone either. :(
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
9:49 a.m.
On 12/01/14 15:50, Rahul Sundaram wrote:
On Mon, Dec 1, 2014 at 5:33 AM, Lars E. Pettersson wrote:
What part(s) of the systemd suite has not been adopted by Fedora so
far? What says that this "component" will not be adopted by fedora?
Look up feature pages to understand which components have been adopted.
My question was "What part(s) of the systemd suite has not been
adopted". Note the not part.
If very few parts have not been adopted, the chances for this component
to find its way into Fedora is greater than if a lot of parts had not
been adopted. I.e. the amount of not accepted parts of systemd in Fedora
is a good indicator whether also this part will find its way into Fedora.
Noone so far has claimed that any component won't be adopted. If
and
when they are actually proposed, a discussion about them would be warranted.
I.e. it might very well be adopted and therefor a discussion about it is
in order. Why wait for the inevitable?
Why? Where? Why shouldn't users be allowed to discuss these
things here?
The same reason you are discouraged from even discuss test or
development releases of Fedora itself in this list. It is offtopic.
This is not about a test or development release. It is about new
functionality finding its way into systemd and whether this
functionality is a good or bad thing. This is very much a user related
discussion and as such it is not off-topic on this mailing list.
In my book, an open discussion is always better than no discussion. You
may have other views on this though...
I find the technical discussion on this subject quite interesting, and
an open discussion may lead to a better understanding of the objective
for the new component and whether it is of use for the normal user or
not, or whether it is duplicating work already done (that very well
might lead to security issues etc.).
Lars
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
8:50 a.m.
Hi
On Mon, Dec 1, 2014 at 5:33 AM, Lars E. Pettersson wrote:
What part(s) of the systemd suite has not been adopted by Fedora so
far?
What says that this "component" will not be adopted by fedora?
Look up feature pages to understand which components have been adopted.
https://fedoraproject.org/wiki/Features/systemd
http://fedoraproject.org/wiki/Features/SystemdPredictableNetworkInterface...
http://fedoraproject.org/wiki/Features/systemd-journal
http://fedoraproject.org/wiki/Features/SystemdLightweightContainers
http://fedoraproject.org/wiki/Features/SystemdCalendarTimers
https://fedoraproject.org/wiki/Features/PackagePresets
Noone so far has claimed that any component won't be adopted. If and when
they are actually proposed, a discussion about them would be warranted.
Why? Where? Why shouldn't users be allowed to discuss these things here?
The same reason you are discouraged from even discuss test or development
releases of Fedora itself in this list. It is offtopic.
Rahul
1:48 p.m.
On 11/18/14 04:20, Rahul Sundaram wrote:
user mailing list of a distribution which doesn't even use the
component
at all yet.
Well, how long do you think it will take until the "component" is being
used then? Systemd have had a tendency to very quickly find its way into
Fedora, and probably this will also do so. I.e., it might not be here
yet, but it is on the door step. And discussions about this is a good
thing, even on this list.
Lars
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
6:30 p.m.
Pete Travis writes:
Whatever the intent, I hope that everyone discovers it from reading
actual
documentation instead of inflammatory comments on indignant speculation about
the intent behind a one sentence feature description like "
resolved: add DNS cache ". I'm not necessarily putting you in that box, Sam,
but these discussions tend to feed on themselves and it makes productive
discourse difficult.
I think that the one-line commit message is the least important issue here.
8:45 a.m.
On Sat, 15 Nov 2014 08:53:59 -0500
Sam Varshavchik <mrsam(a)courier-mta.com> wrote:
Making the rounds of various technical mailing lists yesterday, with
a subject that's typically a variation of "Just for yucks, and giggles" isa
link to a commit to systemd's git, adding DNS caching to systemd; in one, huge 857
line glop. Here's its entire commit message: "resolved: add DNS cache".
And, it's beauty to read. Made me teary-eyed to know that systemd will ca
che my DNS queries. Not sure why systemd, all of a sudden, needs to make DNS queries. But
if it does, it's going to cache them now! Such a sight to behold makes my heart skip a
beat: now, not just bind, or pretty much eve
ry DNS server that automatically caches DNS for you – but so will sy
stemd!
But, seriously folks, systemd's DNS caching achieves absolutely 100% nothing. Really.
Surprised? Well, you'll be shocked to know that the DNS server that systemd queries
for that DNS RR, such as the stock "bind", already automatically caches all
recursive DNS replies!! systemd's own caching produces absolutely zero useful results.
On the oft chance that i
t sends a query for a non-cached RR, the local DNS server will cache the response, before
returning it to systemd, and then use the cached respons
e for all future queries. That's what DNS servers do: provide caching for local
clients. It's inherent in DNS's design: DNS was explicitly designedto use
aggressive caching, it's an internet-wide, distributed, locally cache
d database.
Isn't modern technology amazing?
I'm willing to consider the possibility that I missed something obvious, some obvious
value-added result from caching DNS RRs directly by systemd, and I'll stick around for
someone to enlighten me; or if Occam's razor applies, and the author of that commit
had no idea that bind already automatically caches DNS responses, and, more importantly,
that its cachi
ng algorithms are a result of painful lessons learned from various DNS cache poisoning
attacks, that have circulated around the intertubes, for the la
st couple of years.
The only possible use case for this kind of caching approach would be if:
A) You do not have a local DNS server nearby; and you have non-negligible latencies to
whatever DNS server you use.
B) Your queries tend to be for domains that your DNS servers are not authoritative for,
so they'll benefit from local caching.
So, can someone explain to me how likely this is going to be the case ina typical
deployment scenario that systemd is targeted for; in an average corporate environment
where systemd's alleged benefits will supposedly sh
ine?
I would guess that a typical systemd deployment, in a corporate/business environment,
will certainly have multiple, low-latency DNS servers nearby
, won't that be the case? And, if so, then this is just another potentially
exploitable security hole in systemd, nothing more.
P.S. After I wrote the above, poking around, Google dumped this onto my screen:
http://seclists.org/oss-sec/2014/q4/592
Mental note to myself: go back and check the timestamp of the systemd git commit –
before, or after, this was disclosed…
When will be the kernel embeded in the systemd?
BR, Bob
3:32 p.m.
Hi
On Mon, Dec 1, 2014 at 4:25 PM, Lars E. Pettersson wrote:
I am keen on discussing how new features in systemd (or any other
packages
used by Fedora for that matter) will affect the users of Fedora. The best
place for that is this users list.
By that account why would rawhide or test releases be considered
offtopic? How about development kernel or glibc features?
But I can not see that discussing Fedora users view on new features of
systemd on the systemd mailing lists will lead to any good...
Why wouldn't it?
Rahul
3:25 p.m.
On 12/01/14 22:13, Rahul Sundaram wrote:
In a similar way, development branches of systemd has its own
mailing
list for discussing such functionality called systemd-devel list. Use
that list if you are so keen on discussing development branches of systemd.
I am keen on discussing how new features in systemd (or any other
packages used by Fedora for that matter) will affect the users of
Fedora. The best place for that is this users list.
If I was keen on discussing implementation details of this new feature,
I would use the appropriate systemd mailing list. But I can not see that
discussing Fedora users view on new features of systemd on the systemd
mailing lists will lead to any good...
Lars
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
6 p.m.
On Mon, Dec 1, 2014 at 4:56 PM, Matthew Miller wrote:
If the thread goes off the rails and outside of the scope of
"community assistance, encouragement, and advice" — not to mention the
Friends foundation — that's a different story.
I would suggest that the thread is off the rails long time back and not
enforcing the list guidelines and keeping the list on topic leads to us,
unable to point our own users to the list for help because they have to
wade through rants. A similar problem already plagued the #fedora IRC
channel before more people stepped in. I along with several others spend
hours every week on moderation in Ask Fedora to keep the content focused on
helping users. I think the results are pretty clear.
Rahul
9:49 p.m.
On Mon, 2014-12-01 at 20:14 -0600, Dave Ihnat wrote:
Just to point out how explosive the systemd issue is in the Linux
community, note that Debian has been forked just beause of this:
https://lists.dyne.org/lurker/message/20141127.212941.f55acc3a.en.html
Thanks for the link, not all Debian has gone to the dark side...
In the mean time I will format fedora and load pclinuxos and keep a eye
on Devuan.
Gary.
11:42 p.m.
New subject: Better tools needed - Re: Latest systemd news
On 12/01/2014 05:17 PM, Robert Moskowitz wrote:
Then there was good old 'chkconfig' that produced a nice tablular report
of services that can be controlled. I have yet to find anything close
to this with systemd.
systemctl list-unit-files
8:37 p.m.
Hi
On Mon, Dec 1, 2014 at 9:14 PM, Dave Ihnat wrote:
Just to point out how explosive the systemd issue is in the Linux
community, note that Debian has been forked just beause of this:
https://lists.dyne.org/lurker/message/20141127.212941.f55acc3a.en.html
Yes, I know, this isn't Fedora. But if it's that controversial that an
enire distro will split, we can't ignore the issue
Just to be clear, the "entire distro" didn't split. A couple of folks
(literally just two) who are not Debian contributors have announced a
fork. Whether it amounts to anything in practice remains to be seen.
Rahul
8:44 a.m.
On Thu, Dec 11, 2014 at 03:04:18PM -0500, Bill Davidsen wrote:
More bloat to fail, it may come as a shock, but there are computers
running Linux and not network connected at all (as in no NIC
devices). Bloat for no benefit.
This seems to be based around a misconception. Like most systemd
features, the network components of systemd are provided by separate
daemons and libraries and can easily be subpackaged if there is a use
case where it's meaningful. If you have such a use case *in Fedora*,
please share it (an RFE bugzilla entry is likely to be the most
helpful).
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
2:07 p.m.
Joe Zeff wrote:
On 11/15/2014 08:27 AM, Tom Horsley wrote:
> I've always called systemd the world's fist computer fungus - it wants
> to grow over everything.
Resistance is futile! Your functionality will be assimilated.
Or in this case approximated.
--
Bill Davidsen <davidsen(a)tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
2:04 p.m.
Chris Adams wrote:
Once upon a time, Sam Varshavchik <mrsam(a)courier-mta.com>
said:
> Making the rounds of various technical mailing lists yesterday, with
> a subject that's typically a variation of "Just for yucks, and
> giggles" is a link to a commit to systemd's git, adding DNS caching
> to systemd; in one, huge 857 line glop. Here's its entire commit
> message: "resolved: add DNS cache".
Yet more unreasonable scope creep for the systemd project, and this time
reinventing the wheel for no good reason. There are already perfectly
good resolver libraries, caches, etc.; there is no good reason for
systemd to grow its own.
More bloat to fail, it may come as a shock, but there are computers running
Linux and not network connected at all (as in no NIC devices). Bloat for no benefit.
--
Bill Davidsen <davidsen(a)tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
3416
days inactive
3443
days old
67 comments
21 participants
participants (21)
-
Bill Davidsen -
Bob Marcan -
Chris Adams -
Dave Ihnat -
Frank Pikelner -
Fulko Hew -
Gary Hodder -
Glenn Holmer -
Ian Malone -
Joe Zeff -
Juan Orti Alcaine -
Lars E. Pettersson -
Matthew Miller -
Mike Wohlgemuth -
Paul W. Frields -
Pete Travis -
Rahul Sundaram -
Rick Stevens -
Robert Moskowitz -
Sam Varshavchik -
Tom Horsley