and
> binary size. Hence the advertising refers to the SI size.)
For those too lazy to calculate the difference between 1 GB and 1 GiB: 1
GB equals 953 MiB. We hence should probably stick to to 950 MiB as new
target image size.
Lennart
--
Lennart Poettering - Red Hat, Inc.
-
s, already got a good old german Diplom,
no interest in a Master. (The Bologna process is evil anyway!)
Please be more careful with the facts when insulting somebody, thank you!
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.f
(AF_INET, ...) returning
EAFNOSUPPORT. Just taking away 127.0.0.1 doesn't do anything like that.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Thu, 21.06.12 18:22, Alexey I. Froloff (ra...@raorn.name) wrote:
> On Thu, Jun 21, 2012 at 03:39:43PM +0200, Lennart Poettering wrote:
> > Disabling IPv4 should result in socket(AF_INET, ...) returning
> > EAFNOSUPPORT. Just taking away 127.0.0.1 doesn't do anything like
esult of this will be that the OS will either be in the old state,
or in the new state, but not in half-way state. This should also allow
the user to hard reboot any time without any ill-effect.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
even Restart=on-abort is the best option to
suggest.
I think it would be great if somebody would file an FPC ticket about
this, so that the policy gets amended. But for that we'd first have to
make our mind up what the best option to recommend is.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Mon, 25.06.12 16:13, Lennart Poettering (mzerq...@0pointer.de) wrote:
> I think it would be great if somebody would file an FPC ticket about
> this, so that the policy gets amended. But for that we'd first have to
> make our mind up what the best option to recommend is.
Hmm, ok
minates during the normal runtime.
Anyway, I will spend some time today to make sure this all works
properly, as intended.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
id one. We'll add a new dependency type
to work this nicely, so that if the target is started all services go
up, if the target goes down all services go down, but if individual
services are started/stopped they don't influence the target nor any
other services. In the meantime, please
On Wed, 27.06.12 13:34, Honza Horak (hho...@redhat.com) wrote:
>
> On 06/26/2012 11:01 AM, Lennart Poettering wrote:
> >Also, if you use Restart=always and a service terminates during its
> >initialization phase then we don't try restarts either (well, at least
> >in
em in the bios...
Is there any reason why Fedora doesn't create that file?
(it's a pity FAT can't do symlinks, hence it should just be a copcy of
grubx64.efi)
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
; to systemd package means that they are often unnecessarily delayed.
> Wherever they are moved, I think it is important that package has
> plenty of maintainers who can do small updates as necessary.
I fully agree. The preset files really don't belong in the systemd
package, and it would b
ll it just contains preset configuation bits in the
sense of new "defaults", but not actual user configuration... i.e. it's
the preset state before the user started to configure the hell out of
it, if you understand what I mean...
(But then again, I don't care too much, just m
who need this, and people then
have the free choice which version they want to use.
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
rty of other packages.
Mabye httpd.rpm wants to include a tool that has a similar "feel" like
systemctl, maybe "httpdctl" or so, that covers this, but I am pretty
strongly of the opinion that that has no place in systemd.
Lennart
--
Lennart Poettering, Red Hat
--
devel mail
comments on security from the man page: yes, with
nspawn we do not make any claims about being secure, but that's mostly
inherent to the underlying technologies and hence mostly applies to the
other container managers in the same way too).
So, from my PoV that wiki text should really just say &qu
-e" or /etc/crontab. However, a systemd timer
unit will always be two files, and they will have 2+ lines each. While
the systemd way is certainly more uniform with the rest of service
management, it is definitely a bit more work, and I don't want to be in
competition here...
Lennart
on like .socket, and so on...)
So, we are different here, it's a lot more restricted, and you will have
a per-user systemd instance around if you make use of this, but then
again you get the real deal, not just timer based activation...
Lennart
--
Lennart Poettering, Red Hat
--
devel mai
ibit it perminantly
though, but some components might delay suspends, for example Telepathy
to log you out of your Jabber server...
Normally when you close the lid logind should log something about "Lid
closed" or so... Look around the logs around this to figure out what
mightbe goin
s. For that, simply
read /proc/self/cgroup to find out your own cgroup, and then operate on
that. However, as during the single-writer cgroup transition the kernel
interface how we set things up will change, be prepared that things
might break...
Lennart
--
Lennart Poettering, Red Hat
ke "delay" suspend locks and which don't release them
by the time the timeout we put on that elapses. Or with other words, if
something like Telepathy delays your suspend you should see logind
mentioned that it is responsible for that in the logs. This hopefully
puts enough shame on pe
#x27;t
> have the will to be checking and fixing a file system critical for
> booting, maybe we shouldn't be persistently mounting it rw (back to 1
> above)?
Yeah, Fedora really should set passno to 1 for all physical file systems
it mounts, and that certainly includes the ESP.
(The ESP logic
as if
x-systemd.automount hadn't been used.
Combining x-systemd.automount + noauto however is a way to establish a
mount point and only lazily triggering it on access. And that's what you
want to use here.
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproje
ble media too, one day, so
that the file systems are quickly unmounted after use and hence highly
likely to be in a clean state when removed without manual umounting.
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/lis
@strawberry ~]#
To establish the automount point /boot/efi you need /boot mounted. You
cannot have an automount point nested into an automount point.
It's one of the reasons why I really really dislike the invention of
/boot/efi as the mount point for the ESP...
Lennart
--
Lennart Poetter
ake them simple. Sure, keep writing to the
ESP at a minimum, but don't play games of just moving those writes to
another boot partition that is a lot more fragile. You are not helping
anyone with that...
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
'd be delighted!
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
fedup or so that tells people about this should
/etc/hosts.{allow,deny} have changed from shipped defaults or so.
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedorapro
On Thu, 20.03.14 14:31, Martin Langhoff (martin.langh...@gmail.com) wrote:
> On Thu, Mar 20, 2014 at 1:34 PM, Lennart Poettering
> wrote:
>
> > I wonder whether it wouldn't be time to say goodbye to tcpwrappers in
> > Fedora. There has been a request in systemd u
ty much any Linux installation I
know nowadays has a firewall compiled into the kernel...
Lennart
[1] well, sure tcpwrap resolves DNS dynamically and can use that for
access control, but people who bind access control to DNS really should
find a different job than administrator...
--
Len
stemd
> level, though.
OpenSSH can do this on its own without involving tcpwrap:
https://raymii.org/s/tutorials/Limit_access_to_openssh_features_with_the_Match_keyword.html
It sounds like a much better choice to stick to that instead of
involving tcpwrap, and we should push our users to underst
ame
uuid and stuff. That is a call for trouble.
This is a really awful idea. Really, things like the pre-kernel boot
logic should be kept simple, and what you are suggesting there is just
frickin' crazy.
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproj
can certainly fix that
with adding more docs, or explaining this in the release notes?
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
u that tcpwrap is a
dead-end. I mean, take it as an indication that I am actually taking
your feedback seriously, that I spend a lot of time arguing against
it. If I wouldn't take it seriously I wouldn't have started this
discussion and would certainly not have replied to this message...
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
d remove unnecessary redundancies. And just rewriting something that
is redundant and a bad idea in the first place, certainly doesn't help
there...
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, 20.03.14 20:04, Martin Langhoff (martin.langh...@gmail.com) wrote:
> On Thu, Mar 20, 2014 at 8:00 PM, Lennart Poettering
> wrote:
>
> > A firewall has mechanisms to filter for all domains, however only
> > covering a smaller number of generic, low-leve
On Fri, 21.03.14 00:27, Paul Wouters (p...@nohats.ca) wrote:
> On Fri, 21 Mar 2014, Lennart Poettering wrote:
>
> >I mean, in this day and age we should not consider an ACL language well
> >designed if it basically pushes users to use IDENT and DNS for
> >authentication
On Fri, 21.03.14 12:37, Paul Wouters (p...@nohats.ca) wrote:
> On Fri, 21 Mar 2014, Lennart Poettering wrote:
>
> >>we kinda do have dnssec per default. All DNS servers installed per
> >>default do DNSSEC. Installing dnssec-trigger makes that even more
> >>pervas
On Fri, 21.03.14 13:05, Paul Wouters (p...@nohats.ca) wrote:
> On Fri, 21 Mar 2014, Lennart Poettering wrote:
>
> >As long as -lresolve (i.e. glibc and getaddrinfo()) can't do DNSSEC it's
> >just not there...
>
> You are proposing changing the api of get
On Fri, 21.03.14 20:02, Florian Weimer (f...@deneb.enyo.de) wrote:
> * Lennart Poettering:
>
> >> So offer something with equivalent functionality (and config file
> >> syntax compatibility), with a nice modern clean API and then systemd
> >> and others can be mo
ould have been
> becakward compatible if the developers would not be too lazy
> to care about
Wietse is such a lazy person that he didn't had hosts.allow/.deny
compatibility support to Postfix, isn't he?
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fed
development is never finished, it's a process. You do need
maintains for such things.
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
ater, if we don't know why the users are doing this they
> are likely to do it in the new system as well, and we will end up with even
> a bigger mess implementing the same security theater.
We *do* know that tcpd is 70% insecure non-sense, 100% crappy code, and
about 30% logic th
On Thu, 20.03.14 18:34, Lennart Poettering (mzerq...@0pointer.de) wrote:
> Heya!
>
> I wonder whether it wouldn't be time to say goodbye to tcpwrappers in
> Fedora. There has been a request in systemd upstream to disable support
> for it by default, but I am not sure I want
ding things and we giving it to you. It's a two way street, so
instead of all the negative energy you spend bitching about things, how
about actually doing something really constructive, figuring out a patch
or so, for the relevant things, and submitting that?
Lennart
--
Lennart Poetterin
On Mon, 24.03.14 21:45, Reindl Harald (h.rei...@thelounge.net) wrote:
> and that is the problem with you attitude
Okeydokey, as you wish, you are now in my killfile.
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.
de an alternative
to use tcpwrap with systemd even further on (via tcpd), so I really
don't see what you are upset about.
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
oraproject.org/wiki/Changes/PrivateDevicesAndPrivateNetwork
> >
> > Change owner(s): Lennart Poettering , Dan
> > Walsh, Kay Sievers
> >
> > Let's make Fedora more secure by default! Recent systemd versions provide
> > two
> > per-service switches PrivateDevices=yes/no and
lly-managed accounts.
I think we can cover this one line: "if you do something like that,
don't. if you insist, use nscd". And that should be enough.
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
address families, either all or none. (except for
the weirdness of AF_UNIX sockets in the fs namespace which stay
connectable as long as the fs is reachable, see feature page).
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fed
ly.
Hence: please let's just remove securetty entirely from the default PAM
stacks. It's annoying, it creates a false sense of security, it's a
relict of a different time and not compatible with modern device
management, hotplug, containers, and so on!
Lennart
--
Lenna
On Wed, 09.04.14 22:20, Lennart Poettering (mzerq...@0pointer.de) wrote:
> This sounds entirely backwards, and I'd instead vote for removing
> securetty from the PAM stacks we ship altogether. The concept is
> outdated. It was useful in a time where the primary way to access a
&g
) data of some other file in /usr, so that we can
support suid/sgid binaries nicely), and another one to copy files that
are strictly needed for boot into /etc).
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, 11.04.14 14:41, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:
>
> On 04/11/2014 02:34 PM, Lennart Poettering wrote:
> >Within the systemd project we have been working on a scheme we call
> >"factory" where packages can drop in static descriptions in /usr/
erver-mailing-list.10970.n7.nabble.com/Leopard-underscore-user-names-td11346.html
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, 11.04.14 15:05, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:
>
> On 04/11/2014 02:47 PM, Lennart Poettering wrote:
> >On Fri, 11.04.14 14:41, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:
> >
> >>On 04/11/2014 02:34 PM, Lennart Poettering wrote:
>
On Fri, 11.04.14 15:19, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:
>
> On 04/11/2014 03:11 PM, drago01 wrote:
> >On Fri, Apr 11, 2014 at 5:05 PM, "Jóhann B. Guðmundsson"
> > wrote:
> >>On 04/11/2014 02:47 PM, Lennart Poettering wrote:
> >>
On Fri, 11.04.14 15:49, Colin Walters (walt...@verbum.org) wrote:
> On Fri, Apr 11, 2014 at 10:34 AM, Lennart Poettering
> wrote:
> >
> >I am really not convinced that this is a good idea and will really
> >fly. Having a fully static passwd file can't really work
boot. The fomer is the messy bit.
Maybe the cheap way out is to disallow suid/sgid binaries in /usr/bin
for dynamically assigned UIDs/GIDs. I this day and age, are there still
good usecases for that?
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
http
#x27;s one thing to sync system users against LDAP, but storing them there
exclusively cannot work, and is currently not supported, and is
something we should not support.
> I think this scheme is baroque and prone to nasty failures in real
> deployment. Please don't do that.
Nope. The
rs. Sorry.
I also don't see sssd covering cases where /var is not around and where
we can "disconnected" updates, the way Colin suggests.
I also didn't see sssd in control of system users at all, but merely of
normal users.
Lennart
--
Lennart Poettering, Red Hat
--
d
d, hence we couldn't claim 100% compat
with such a scheme.
> environment (say, everything via DHCP, no VPNs, no IPSec, no bridges,
> nothing else), and telling both users and application developers not to
Note that networkd supports static configuration, bridges and some forms
of
On Tue, 22.04.14 06:01, Lennart Poettering (mzerq...@0pointer.de) wrote:
> > environment (say, everything via DHCP, no VPNs, no IPSec, no bridges,
> > nothing else), and telling both users and application developers not to
>
> Note that networkd supports static configuration
where and thus do this according to
available resources. THe push model is prone to logging bursts
overwhelming log servers if you scale your network up.
I am pretty sure that a pull model should be the default for everything
we do, and push only be done where realtimish behaviour is desired
d. Sometimes it's the log
server behind the NAT that is the problem, sometimes it it is the log
client behind the NAT that is the pronlem. If you consider push vs. pull
then you simply reverse which one is the bigger issue.
Note that the journal protocol is HTTP, so it's probably as proxy and
hem on package installation/deinstallation
correctly. And when that's done we should probably ask FPC to propose
usage of these macros in the guidelines, and then make the changes to
the packages...
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraprojec
On Thu, 20.03.14 18:34, Lennart Poettering (mzerq...@0pointer.de) wrote:
> Heya!
>
> I wonder whether it wouldn't be time to say goodbye to tcpwrappers in
> Fedora. There has been a request in systemd upstream to disable support
> for it by default, but I am not sure I want
se, system users cannot be defined in /var, since we
allow /var to be mounted late.
Defining essential users in /var also has the problem that they are lost
when the same /usr is used to boot a large number of instances with a
disjunct /var each time.
Lennart
--
Lennart Poettering, Red Hat
--
devel
ce there's little to do really, except dropping the
deps, and leaving everything else in place...
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
count the docs/man pages of the RPMs, how much does kmod,
udev, systemd actually contribtue in bytes to your docker images?
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Cond
On Tue, 29.04.14 10:37, Daniel J Walsh (dwa...@redhat.com) wrote:
>
> On 04/29/2014 06:33 AM, Lennart Poettering wrote:
> > On Mon, 28.04.14 17:01, Daniel J Walsh (dwa...@redhat.com) wrote:
> >
> >> The problem is lots of services require systemd because they shi
On Tue, 29.04.14 16:58, Alexander Larsson (al...@redhat.com) wrote:
> On tis, 2014-04-29 at 12:33 +0200, Lennart Poettering wrote:
> > On Mon, 28.04.14 17:01, Daniel J Walsh (dwa...@redhat.com) wrote:
> >
> > > The problem is lots of services require systemd because the
On Tue, 29.04.14 18:03, Alexander Larsson (al...@redhat.com) wrote:
> On tis, 2014-04-29 at 17:40 +0200, Lennart Poettering wrote:
> > On Tue, 29.04.14 16:58, Alexander Larsson (al...@redhat.com) wrote:
> >
> > > On tis, 2014-04-29 at 12:33 +0200, Lennart Poetteri
On Tue, 29.04.14 15:36, Marcelo Ricardo Leitner (marcelo.leit...@gmail.com)
wrote:
> Em 29-04-2014 12:27, Lennart Poettering escreveu:
> >On Tue, 29.04.14 10:37, Daniel J Walsh (dwa...@redhat.com) wrote:
> >
> >>
> >>On 04/29/2014 06:33 AM, Lennart Poettering w
way on 'may or not be a security
> > liability'.
> >
> > It's part of getting Fedora somewhat optimized for containers.
> >
> > Anyway, sounds like we have even already agreed to remove the
> > Requires, if I'm reading the thread corr
edorahosted.org/fpc/ticket/425
>
> Next I will create a change request if the ticket is approved.
Note that just dropping systemd from your images might not be the best
choice, as you then have no owners for a lot of drop-in dirs, which made
be bad for verifying the software installed in the c
7;s probably where they focus most. But still fear
> something ending up executed via unwanted/unpredicted ways,
> specially when systems are getting more integrated, clever and
> smarter day after day.
Well, that's theatre. It's not security engineering.
Lennart
--
Lennart
d Zbigniew's brings us a good step closer to that
goal, even if it might not bring us all the way there yet.
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
eed to start it from ttyN... Note
that only tty1-6 get logins by default, but you can configure that with
NAutoVTs= in /etc/systemd/logind.conf.
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora
oS class (ie, making sure that remote
> logging works during a DoS attack caused by malware).
>
> If you feel that HTTPS is the correct protocol then please consider using
> another port number than 443.
It's port 19531 by default.
Lennart
--
Lennart Poettering, Red Hat
--
On Mon, 05.05.14 12:49, Florian Weimer (fwei...@redhat.com) wrote:
> On 05/05/2014 12:36 PM, Lennart Poettering wrote:
>
> >>If you feel that HTTPS is the correct protocol then please consider using
> >>another port number than 443.
> >
> >It's port
e by Fedora always placing both
/usr/bin and /usr/sbin in the $PATH, and shipping a number of binaries
in both places...
We really should get rid of the destinction, and make all of /bin,
/sbin, /usr/sbin a symlink to /usr/bin, and then never bother again
about $PATH orders and namespac
On Mon, 05.05.14 11:32, Simo Sorce (s...@redhat.com) wrote:
> On Mon, 2014-05-05 at 16:43 +0200, Lennart Poettering wrote:
> > On Mon, 05.05.14 10:35, Kaleb S. KEITHLEY (kkeit...@redhat.com) wrote:
> >
> > > On 05/05/2014 10:28 AM, Adam Jackson wrote:
> > > &
On Mon, 05.05.14 11:45, Felix Miata (mrma...@earthlink.net) wrote:
> On 2014-05-05 12:34 (GMT+0200) Lennart Poettering composed:
>
> >Felix Miata wrote:
>
> >>How can I get it to go there and stay there? When starting F21 in
> >>multi-user, logging in on tty3 an
On Mon, 05.05.14 12:24, Felix Miata (mrma...@earthlink.net) wrote:
> On 2014-05-05 17:55 (GMT+0200) Lennart Poettering composed:
>
> >On Fedora tty1 is the graphical login, since a long time.
>
> I've managed to avoid that in order that my boot messages tail stays
> th
-of-sync. (Also the
kernel cgroup rework does away with orthogonal trees per controller,
hence making use of this will make it hard to make your code work on
fedora, as soon as we have turned the kernel cgroup rework on in the
fedora kernel).
Lennart
--
Lennart Poettering, Red Hat
--
devel ma
or the file to be moved.
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 the
> depsolving issues as suggested by James Antill.
I really don't understand why /usr/lib/os-release should have an API to
modify. It describes the vendor operating system image, really, and his
hence strictly not dynamic. We should never invent mechanisms that make
files in /usr subject
will have. The Products then add to this definition. A
> basic piece of it is mandatory, but the outer edges are add-ons.
I am not sure this is really what /etc/os-release is for. It's for
declaring operating system names and versions, not really for containing
a list of packages you have i
On Mon, 30.06.14 17:31, Stephen Gallagher (sgall...@redhat.com) wrote:
>
>
> > On Jun 30, 2014, at 5:15 PM, Lennart Poettering
> > wrote:
> >
> > On Mon, 30.06.14 16:43, Stephen Gallagher (sgall...@redhat.com) wrote:
> >
> >>>> Well, ideall
. 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
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
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 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
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
y's network? Note that Fritzbox is not a random crappy router,
it's probably of the better products you can find.
How do other popular desktop/consumer OSes deal with this? Windows,
MacOS, iOS, Android, ChromeOS? Does any of them do client-side DNSSEC
validation by default and how are they d
On Mon, 07.12.15 10:48, Tomas Hozza (tho...@redhat.com) wrote:
> On 04.12.2015 15:57, Lennart Poettering wrote:
> > On Tue, 01.12.15 11:15, Tomas Hozza (tho...@redhat.com) wrote:
> >
> >> You are not mistaken.
> >>
> >> This is the third time, becaus
uests take...
DNS and DNSSEC are designed to scale, with all its caching,
forwarding, offline signing and so on. By then pushing the whole
traffic through HTTPS you completely trash all that...
> This is part of dnssec-trigger documentation, since it is used as the
> mean to reconfigure Unboun
n't allow
anything below my domain except what I define here or delegated".
The problem is pretty much limited to top-level domains, where those
routers and company networks invented stuff.
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
uld you know .foocorp in advance?
I am pretty sure these things need to work out-of-the-box, and that
means a whitelist cannot really work.
Lennart
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
801 - 900 of 1811 matches
Mail list logo
