does this mean for you as a packager?
Excellent!
Thank you very much for working towards this! I think it would be
great to ship without sysv scripts!
Thanks!
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/lis
l come along and play the same game with the actual device volume,
and you won *zero*.
Don't mix flat volumes with misbheaving apps. Turning off flat volumes
is a hack around the broken apps at best, and completely pointless..
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel
eds to be fixed first, but other
than that? Suddenly all binaries are available in both paths. That
means pretty much all scripts that hardcode one or the other path
(maybe because ported over from another distro which sticks some
binaries in a different path of the two than us) will work on our
systems. That certainly *improves* compatibility with external
software, not breaks any.
But anyway, I think we can end the discussion here. You clearly have a
problem with me personally, and I should probably not even have
answered even once...
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On Fri, 14.08.15 17:58, Matthew Miller (mat...@fedoraproject.org) wrote:
> On Fri, Aug 14, 2015 at 07:24:16PM +0200, Lennart Poettering wrote:
> > Given that sbin is in $PATH for unprivileged users too the seperation
> > is really pointless, since it's now only the $PA
ll two different things to the
two paths. It's really ugly from mock...
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On Fri, 14.08.15 02:50, Reindl Harald (h.rei...@thelounge.net) wrote:
> is systemd now orphaned in Fedora or why is there no single comment over 3
> months from a maintainer and a upstream available fix is also ignored for a
> week without any comment
> https://bugzilla.redhat.com/show_bug.cgi?id=
On Thu, 30.07.15 19:57, Lennart Poettering (mzerq...@0pointer.de) wrote:
> Heya!
>
> I'd like to ask everybody to test kdbus on Rawhide. Josh thankfully
> added it to the Rawhide kernel packages, and our systemd RPMs come
> with built-in support, too now. If you are r
o
the userspace components, not to the kernel part. Hence you do need
both the new kernel and the new systemd from rawhide.
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On Thu, 30.07.15 16:59, Orion Poplawski (or...@cora.nwra.com) wrote:
> On 07/30/2015 04:54 PM, Orion Poplawski wrote:
> > On 07/30/2015 11:57 AM, Lennart Poettering wrote:
> >> Heya!
> >>
> >> I'd like to ask everybody to test kdbus on Rawhide. Josh thank
Heya!
I'd like to ask everybody to test kdbus on Rawhide. Josh thankfully
added it to the Rawhide kernel packages, and our systemd RPMs come
with built-in support, too now. If you are running an up-to-date
Rawhide system adding "kdbus=1" to your kernel command line is hence
everything you need to
akes it difficult to drops caps sanely if you want to ensure they are
dropped in all threads at the same time, and not just in whatever
thread was the one started first...
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/ma
7;s worse is that in kernels before 2.6.24 passing caps across
exec() actually worked fine. Kernel broke API heavily in this regard
by introducing fcaps and altering the caps inheritance logic then.
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.or
On Mon, 15.06.15 11:15, Petr Lautrbach (plaut...@redhat.com) wrote:
> Dne 13.6.2015 v 19:07 Lennart Poettering napsal(a):
> > On Fri, 12.06.15 19:00, Miroslav Grepl (mgr...@redhat.com) wrote:
> >
> >> On 06/12/2015 12:17 PM, Lennart Poettering wrote:
> >>> On
On Fri, 12.06.15 19:00, Miroslav Grepl (mgr...@redhat.com) wrote:
> On 06/12/2015 12:17 PM, Lennart Poettering wrote:
> > On Thu, 11.06.15 06:51, Jan Kurik (jku...@redhat.com) wrote:
> >
> >> = Proposed System Wide Change: SELinux policy store migration =
> >&g
boot. Is that a problem for this proposal, and if not, why not?
Does this require changes in systemd? Does this require changes
anywhere in the core OS, outside of selinux' own userspace?
And so on...
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fe
it nicer I think then the alternatives (i.e. the fact that
it renders the image names into URL via a fixed template, and that it
uses tags for exposing this information is pretty nice).
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fed
oot file system shall stay read-only during
runtime, since booting ro and then remounting rw makes sense, but
booting rw and then remounting ro certainly doesn't...
Hence I think FEdora is fine as it is.
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
t.com/show_bug.cgi?id=1201979 is about systemd
> being stupid and rerunning root fsck, which sometimes triggered the
> first issue. I just posted a patch upstream:
> http://lists.freedesktop.org/archives/systemd-devel/2015-May/031445.html
Well, note that this one is triggered if the system
le.
systemd-timesyncd implements this, too, it will ensure that the clock
is monotonic at least. It will save the local clock to disk at
shutdown and each time it acquires an NTP fix.
fedora doesn't use timesyncd by default however.
Lennart
--
Lennart Poettering, Red Hat
--
devel m
On Wed, 29.04.15 16:46, Lubomir Rintel (lkund...@v3.sk) wrote:
> On Wed, 2015-04-29 at 14:00 +0200, Ralf Corsepius wrote:
> > On 04/28/2015 03:52 PM, Lennart Poettering wrote:
> >
> > > And no, this *never* worked fully on Linux, and it never will,
> > &
something
we simply cannot support at all. Either get your RTC set to UTC like
everybody else, or disable time-based fsck like everybody else, but
if you enable both then you are purely on your own.
Essentially you are asking us to support multi-boot with windows, but
you ignore that it's win
arliest boot to latest shutdown.
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
the hibernation resume logic
in the initrd on its own without any external support, see the man
page systemd-hibernate-resume(8). This does not require any explicit
support in Dracut.
pm-hibernate is obsolete as others already mentioned.
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
On Mon, 02.03.15 10:03, Mauricio Tavares (raubvo...@gmail.com) wrote:
> On Mon, Mar 2, 2015 at 9:42 AM, Lennart Poettering
> wrote:
> >> We are continuing to work on making running systemd within a container
> >> better.
> >> I am trying to get a /run on tmpf
he
whole thing has more holes than a swiss cheese. Maybe one day the
security holes can be fixed, but as of now, it's simply not
secure. And this "information leak" is certainly the least of your
problems...
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
rse, that it is apparently Leonard Pottering's
> announced desire to stop people from using /etc/
Hmm? What? I figure "Leonard Pottering" cannot be a misspelling of my
name, given that what you claim his desire to be is certainly not even
remotely mine.
Plese stop FUDding
On Wed, 25.02.15 11:16, Chris Adams (li...@cmadams.net) wrote:
> Once upon a time, Lennart Poettering said:
> > We generally default "secure". The thing is that with sysrq you can
> > kill arbitrary processes if you have acecss to the console, and other
> > thing
official fedora live CDs are unsuitable for system recovery
> tasks; you have to change sysrq value every time you use live CDs or
> build your own live CD.
I figure for livecds it would be fine to override this.
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.f
On Mon, 23.02.15 10:52, David Cantrell (dcantr...@redhat.com) wrote:
> On Mon, Feb 23, 2015 at 04:27:22PM +0100, Lennart Poettering wrote:
> > On Mon, 23.02.15 08:17, David Cantrell (dcantr...@redhat.com) wrote:
> >
> > > > Communication is a two way street, and as
the suse,
debian, ubuntu MLs either.
> For example, now if I manipulate /etc/resolv.conf for whatever reason,
> and I edit it with "vi" or a management tool like "chef" that is
> unaware of symlinks, I'll break the link. Will systemd correctly
&g
sary.
The /etc/os-release to /usr/lib/os-release is hardly a change in the
public interface, it keeps compat by leaving a symlink in /etc.
And jeezuz, I didn't push this change into Fedora. Other people did,
without talking to me.
Really, this is neither much of a compat break, nor is this som
ution
> need to be coordinated in Fedora among the affected components.
David, I see how you would like to pin this all on systemd's
supposedly bad communication. But coming back to the /etc/resolv.conf
issue: it really just boils down to the fact that you knew the change
was coming 6 mo
s we could have likely avoided the
> breakage while the change was made altogether.
Good, please ping me about changes like this next time then, and I am
happy to comment!
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
ion is a two way street, and as an upstream I cannot be in
the business of pinging every single downstream about every single
change individually, in particular if I consider the change
unimportant.
To learn about changes upstream, please follow the upstream
discussions, thank you.
Lennart
--
Len
On Fri, 20.02.15 11:04, Dennis Gilmore (den...@ausil.us) wrote:
> On Fri, 20 Feb 2015 17:36:17 +0100
> Lennart Poettering wrote:
>
> > On Fri, 20.02.15 16:24, Peter Robinson (pbrobin...@gmail.com) wrote:
> >
> > > >> > Sorry for the inconve
On Fri, 20.02.15 11:07, Dennis Gilmore (den...@ausil.us) wrote:
> On Fri, 20 Feb 2015 11:04:13 -0600
> Dennis Gilmore wrote:
>
> > On Fri, 20 Feb 2015 17:36:17 +0100
> > Lennart Poettering wrote:
> >
> > > On Fri, 20.02.15 16:24, Peter R
like this? Isn't 6 month *ample* time?
>
> Likely not, not everyone has the same schedule as upstream systemd, in
> a lot of cases they don't know it's broken until things land and teams
> have other priorities.
OK, got it, will let everybody know now of changes 5 ye
uch time do you think is appropriate for fixing a file copy
routine in anaconda? 12 months? 18 months? 2 years?
Also, NM fixed a similar issue with /etc/resolve.conf in their code a
long time ago, to my knowledge. Am I so misguided to assume that
Anaconda can fix a fricking file copy too, in all thos
opers. By not providing them in a
container we are certainly not making things easier for people...
But anyway, I can see that people disagree with this... I am not
convinced though that we should fuck up the packaging of systemd too
badly, just to accomodate for broken ideas...
Lennart
--
L
v/null 2> /dev/null" (at least the ones done
via our macros), and hence should become NOPs if systemd itself is
missing...
Not enthusiastic,
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
> /tmp, but I agree this would cause confusion. For example a user
> copies something to /tmp and then tells the admin or another user to
> look at it, and the admin can not see it.
Also the fstab option "users" becomes useless with this scheme.
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On Wed, 21.01.15 14:34, Huzaifa Sidhpurwala (huzai...@redhat.com) wrote:
> On 01/20/2015 05:59 PM, Lennart Poettering wrote:
>
> >
> > Well, /tmp is used by X11 among other for IPC across user
> > boundaries. If you give each other their private instance of it,
>
e sessions through logind very
precisely. However, X11 and the mount propagation breakage are real
blockers to make this useful in the general case.
This idea can only fly for very special systems where the propagation
is irrelevant. It's not compatible with admin workflows, at all.
Lennart
;s not just OpenSSH
that is dropping it...
tcpwrap should really be removed. Having such crap, unmaintained code
responsible for security checks is completely backwards.
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
> polkit authorization check. E.g. running "timedatectl set-time 12:00:00"
> and taking 5 seconds to type the password sets the clock to 12:00:05,
> not 12:00:00.
This would be useful functionality in the upstream version, I'd really
like to see a patch added for that.
Len
mer unit in
/etc/systemd/system from a shell script, and then issue "systemctl
daemon-reload" and start it with "systemctl start".
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/deve
On Tue, 25.11.14 11:08, Michael Catanzaro (mcatanz...@gnome.org) wrote:
> On Tue, 2014-11-25 at 17:15 +0100, Lennart Poettering wrote:
> > I am sorry, but timedated is really not the place to control NTP
> > *server* software. It's simply, desktopy stuff, for controlling NTP
&
On Tue, 25.11.14 18:04, Florian Weimer (fwei...@redhat.com) wrote:
> On 11/25/2014 05:15 PM, Lennart Poettering wrote:
> >Really? if you want a UI that controls whether NTP server software is
> >running, why not call into the EnableUnitFiles() APIs directly?
>
> Both chron
out of the initil transaction and all is good.
The way to configure server software is via "systemctl enable" and
"systemctl disable" not via "timedatectl".
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://adm
networked services a logic like this is relatively easy to
implement: if a daemon figures out that it has nothing to process
anymore, it can simply exit(), and that's it.
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
will exploit what it can exploit,
and won't what it doesn't have any pre-generates exploit parameters
around. Or you have a "smart" worm, where a human attacker is
behind. In that case the attacker can easily look at the binary
versions of whatever he finds on the target systems
that package fixed!
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
cosmetic/unrelated.
>
> Readahead was removed from systemd, so if you were using it, you should
> remove stale symlinks.
I figure systemd.rpm is currently missing the right postinst scripts
to remove those automatically on upgrade...
Lennart
--
Lennart Poettering, Red Hat
--
devel m
On Fri, 31.10.14 16:20, Lennart Poettering (mzerq...@0pointer.de) wrote:
> On Fri, 31.10.14 16:13, Michal Schmidt (mschm...@redhat.com) wrote:
>
> > On 10/31/2014 03:42 PM, Kevin Fenzi wrote:
> > > On Fri, 31 Oct 2014 14:01:12 +0100
> > > Lennart Poettering wrote
On Fri, 31.10.14 16:13, Michal Schmidt (mschm...@redhat.com) wrote:
> On 10/31/2014 03:42 PM, Kevin Fenzi wrote:
> > On Fri, 31 Oct 2014 14:01:12 +0100
> > Lennart Poettering wrote:
> >
> >> So the problem appears to be that gssproxy.service been ordered before
&
ify
DefaultDependencies=no), hence there's an ordering cycle.
Most likely some NFS maintainers tried to move gss-proxy.service into
the early boot, and didn't set DefaultDependencies=no.
That said, services running in early boot must be written in a
specific style (i.e. not assume /var to
On Wed, 22.10.14 14:11, Roberto Ragusa (m...@robertoragusa.it) wrote:
> On 10/21/2014 10:02 PM, Lennart Poettering wrote:
>
> > Maybe
> > that's actually a strategy to adopt here: upload the encryption keys
> > into the firmware as efi vars, and then pull the
but this
requires isolating things first.
We are working on app sandboxes, and they will make this available,
but it's the traditional Linux model cannot really deliver this.
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedorapr
logic is
about making the test matrix smaller, and adding determinism where it
normally is missing.
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
the machine is used by noobs only, or because
the machine is buried somewhere under the see, or where so many
instances of the machine are running that a human admins don't scale.
Hope that makes some sense.
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
hdd passphrase and a user
passphrase at boot. It has been a long-time todo list item for systemd
to add the hdd passphrases (with strict expiry) to the kernel keyring
and then optionally pull them out there for gdm's autologin mode, so
that they can be used for decrypting the gnome keyring and
suc
On Mon, 20.10.14 15:08, Matthew Miller (mat...@fedoraproject.org) wrote:
> On Mon, Oct 20, 2014 at 08:56:19PM +0200, Lennart Poettering wrote:
> > But again, I am not sure I understand what is going on here. Is
> > systemd now optional in Fedora?
>
> I guess to some
tter as the command should be
suffixed by >/dev/null 2>&1 || : anyway...
But again, I am not sure I understand what is going on here. Is
systemd now optional in Fedora?
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraprojec
rkManager).
I am more concerned about code written by admins and users. I kinda
hope that we don't ship too massive shell programs in Fedora, (well,
except of course autoconf scripts...), but I am pretty sure that shell
is one of the most common languages used by admins to do thing
y much break API there.
In general, I am pretty sure that except a couple of programming
language or UNIX aficionades very few people can actually correctly
separate bashisms from true bourneshellisms.
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproje
let's please stick with one shell and
one shell only, and let's stay with bash. Thank you.
Let's not waste our time with this, please!
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
do your homework and split things up into privileged and
non-priviliged parts from the beginning.
The blivet-ui thing in this regard is certainly not an improvement over
g-d-u, it's a step back.
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
to set up repositories. As one
git repo or as many. If your biggest criticism is about code hosting
issues, then things can't be that bad...
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fed
good as a news
outlet... Also, the "group" is pretty much one invidual, Billy Estes.
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
e can make upstream and in the systemd rpm
in fedora, don't start doing things like fakesystemd/systemd-container
without first trying to do these things properly, upstream and in the
default RPM.
For example, let's split out the hwdb stuff in Fedora, and maybe some
other things, and then
emd was entirely news to me under this name...
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
one works
> >too...
>
> We've talked about this on Flock - it's not only about disk space
> but also about security reasons (CC'ing Dan Walsh). My goal was not
Dan, can you elaborate what the rationale for this is?
> to have needless junk in base image - if we are not go
lly any value in doing this weird stuff
for a fricking 150K?! Fedora has no bigger fishes to fry?
The systemd-container or fakesystemd stuff sounds awfully adhoc. Can we
please always discuss this first, and see if we can find a different
solution? We don't need three dif
is sounds all very much not thought to the end.
Can you please explain what these packages precisely do, and why they exist?
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
here was already a systemd-mini, and now a fakesystemd, I mean,
what is this all about?
Anyone?
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
es might be easy to resolve, but a big chunk
really isn't. And our core OS stuff is full of it. I think you
underestiate the complexity of this.
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
at texlive packaging is an absolute disaster, where things are
split up to the maximum possible (> 20% of the packages I have on my
machine now are texlive packages, just because i use latex beamer from
time to time...)
Of course, this kind of pragmatism makes bootstrapping fedora on some
new
ion, that looks fishy to me.
The init system of Fedora is systemd. What did you expect?
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
7;s the
real reason for that? If the systemd package isn't optional anyway, why
is this the dep you start with and asking people to complicate things
for?
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
splitting things up into a million of subpackages,
unless you have a ver good reason for a split.
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
e removed the systemd-units package a while after systemd was the
only init system we supported on Fedora...
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
onale here? I mean, we have so many dependencies, if you
want to minimize them, you have a lng way to go...
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On Mon, 18.08.14 13:25, Richard W.M. Jones (rjo...@redhat.com) wrote:
> On Mon, Aug 18, 2014 at 02:21:19PM +0200, Lennart Poettering wrote:
> > On Fri, 15.08.14 22:21, Nico Kadel-Garcia (nka...@gmail.com) wrote:
> >
> > > > I just reverted the "two
ugged in drives stay around on physical media. Dynamic
stuff shouldn't be placed on persistent disks.
This change has been made a long time ago and for good reasons, I really
don't see a point in complaining about this now.
Lennart
--
Lennart Poettering, Red Hat
--
deve
file. For instance units systemd
will look for both the .d/ directory of the instance and of the template.
Hence:
mkdir -p /etc/systemd/system/systemd-fsck@.service.d
echo "..." > /etc/systemd/system/systemd-fsck@.service.d/foobar.conf
systemctl daemon-reload
Allows you to exte
rence to syslog in the docs, to avoid the confusion...)
> Also, I suspect I need to add this service to a target unit. What would be
> the most appropriate one? Currently it's initrd.target.
This sounds appropriate for an initrd service.
Lennart
--
Lennart Poettering, Red Hat
--
dev
On Mon, 04.08.14 18:30, Lennart Poettering (mzerq...@0pointer.de) wrote:
> To make this more confusing, to my knowledge Ubuntu (or is it Debian as
> its upstream?) actually patches /run/media/$UID back into /media. Or at
> least I did that. It's stupid, and a security hole, and t
y be dropped from FHS, as it it's
really pointless, and is nothing one would ever use today. In fact, our
filesystem.rpm package should really stop shipping that (but then again,
I mean, it also ships /var/gopher, ...)
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lis
les with some timestamp in the mmap, before using the data. And if the
mtime is out of date it needs to ping the server, to sync on. But if you
do that, then there's really no need for inotify, again...
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.
uery you get (well, but not more often than once per 1s or so), and
reread the file if the mtime changed. That way you have to issue one
stat() call every 1s if you are busy, and do nothing if you are
not. Which sounds like a good deal. Much simpler and safer than inotify.
Lennart
--
L
emd,
> do the changes get lost?
Nope, what the admin changes will take effect. The only thing that might
happen that if you delete a user it might be recreated the next time
sysusers runs.
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On Thu, 10.07.14 08:17, Oron Peled (o...@actcom.co.il) wrote:
>
>
> A non-API related question...
>
> On Thursday 10 July 2014 01:49:41 Lennart Poettering wrote:
> > Please understand that we are not duplicating "adduser" here. Already in
> > the name of t
cate implementations, and keeping
> specialized knowledge private to specialized modules as a “stacking
> game” is not helping this discussion.
Well, we need to solve a very simple problem with sysuers, and we have a
very simple API for that in glibc, and hence it appears clearly the
right decision for us to use glibc.
I can see that you disagree, but I figure we have to agree to disagree
on this.
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
rrently deviate
greatly in, and we needed somethign simple, safe, somewhat vwidely
available and capable of running in earliest boot. The glibc APis
provide that, no other API does that.
Oh, also, libuser is a glib API. Nothing against glibc, but for the
low-level stuff we do that runs with not
ek
I am sorry, but to make this very clear: sssd has not place in early
boot or in smaller setups. The problems we we want to solve with systemd
we try to solve generically, and this means that I am not telling people
to pull in sssd into the smallest of devices.
sssd/libuser is fine fo
ot pretty... Not sure though what other options there are,
that would be better...
Anyway, I do like to see this feature implemented in Fedora. I think
it's really crucial to get this done.
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https:
On Mon, 07.07.14 17:07, Pavel Raiskup (prais...@redhat.com) wrote:
> On Monday 07 of July 2014 15:57:30 Lennart Poettering wrote:
> > On Mon, 07.07.14 14:48, Pavel Raiskup (prais...@redhat.com) wrote:
> > > > I'd always advise against inventing addition configurat
On Mon, 07.07.14 14:48, Pavel Raiskup (prais...@redhat.com) wrote:
>
> On Friday 04 of July 2014 00:09:03 Lennart Poettering wrote:
> > On Mon, 23.06.14 16:23, Pavel Raiskup (prais...@redhat.com) wrote:
> > > $ cat /etc/postgresql/postgresql@com_example
> > > PG
On Thu, 03.07.14 19:11, Tom Lane (t...@sss.pgh.pa.us) wrote:
>
> Lennart Poettering writes:
> > Please migrate away from ".include", please use .d/ drop-ins instead. We
> > kinda are deprecating ".include", only support it for compatibility
> > in
. It's OK to copy unit files from
/usr/lib/systemd/system into /etc/systemd/system and edit it there.
I'd always advise against inventing addition configuration files that
are neither the daemons own, nor systemd's.
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
501 - 600 of 1811 matches
Mail list logo
