Re: [systemd-devel] [PATCH] swap: introduce Discard property
On Mon, Sep 29, 2014 at 06:52:12PM +0200, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Sep 29, 2014 at 08:35:04PM +0400, Andrei Borzenkov wrote:
В Mon, 29 Sep 2014 17:16:25 +0200
Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl пишет:
The problem with reading but back discards settings remains.
Seems like the most natural solution is to extend /proc/swaps. The only
place where these flags are printed right now is in dmesg during swapon.
I have talked about this issue with Lukas (CC:) who is working on
discard stuff in kernel. I hope we will see any solution :-)
Yeah, but how can you extend /proc/swaps in a backwards compatible way?
Like many kernel interfaces, it was designed with no thought towards
extensibility. A new file would have to be created (/proc/swapinfo?).
Frankly, the /proc concept is broken. It designed as human readable
kernel interface (e.g. cat /proc/mounts), but it's horrible as
interface to distribute information to userspace.
It's painful that kernel provides information by formatted files where
is necessary to care about backward compatibility. The better thing is
sysfs concept where is attribute (info) per file. It's easy to extend,
easy to parse (let's imagine /proc/swaps/sda1/{discard,priority,...}
files :)
Karel
--
Karel Zak k...@redhat.com
http://karelzak.blogspot.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: Honor usr=, usrfstype= and usrflags=
Ronny Chevalier wrote on 30/09/14 20:28: Hi, 2014-09-30 21:18 GMT+02:00 Tobias Hunger tobias.hun...@gmail.com: Any feedback at all? Please? Am I doing something wrong in posting my patch here? No you just need to wait that someone review your patch. It rarely takes more than 2 weeks. Also note that Lennart specifically is on vacation at the moment and this is likely one he'd want to review himself. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Compatibility between D-Bus and kdbus
(Cc'd to the systemd mailing list because sd-bus is the reference implementation of the user-space side of kdbus, but please join the dbus list and follow-up there if you are interested in D-Bus.) I've recently been looking at kdbus as a transport for D-Bus messages, and how compatible or otherwise it is with traditional stream-based D-Bus (and in particular, dbus-daemon, the reference implementation of stream-based D-Bus). My intention here is to replace dbus-daemon on Linux with something that does not have dbus-daemon's limitations, but avoid making existing software non-functional or insecure in the process. See https://bugs.freedesktop.org/show_bug.cgi?id=84188 for my attempts to document the current state of kdbus in the D-Bus Specification. I have not reviewed quality-of-implementation except where I happened to notice things as I went past, and I have not yet looked at Samsung/Tizen's patches adding a kdbus transport to libdbus and GDBus; for now I'm using sd-bus as my only reference for the user-space parts. Here are the likely compatibility issues that I can see in my first pass through: System bus access-control policy I think this is the biggest point of incompatibility. In dbus-daemon there is a needlessly elaborate access-control language; in kdbus, there is a much simpler and more realistic access-control language, which specifically does not look into message payloads. This is far easier to reason about than what dbus-daemon does, but it's a problem for any system service that assumes that its existing per-interface or per-method access-control will be applied, such as Avahi denying access to SetHostName. It is not acceptable for such services to get instant security flaws as a result of their D-Bus implementation being upgraded from a version that does not support kdbus to a version that does. Unfortunately, last time we discussed this, we didn't have a particularly good solution. If I remember correctly, the least bad solution anyone could think of was to introduce a new pseudo-bus-type alongside DBUS_BUS_SYSTEM (and its equivalent in other libraries like GDBus), perhaps called DBUS_BUS_SYSTEM_UNTRUSTED or something (better names welcome), with its own shared connection: connections to that bus type are not assumed to filter messages by their payload, and method-call recipients are expected to use Polkit or similar, or do their own simplistic access-controls like must be uid 0 by calling GetConnectionUnixUser or GetConnectionCredentials on the sender's unique name. On non-kdbus systems, it would just be the same thing as DBUS_BUS_SYSTEM; on kdbus systems, DBUS_BUS_SYSTEM would refuse to use the kdbus transport, and fall back to stream-based D-Bus compatibility mechanisms like systemd-bus-proxyd. That would enable individual libraries and applications to opt-in to using this new shared connection when they have been audited for safety, with the goal being that everything eventually moved to it, and nothing connected to DBUS_BUS_SYSTEM any more. I'm also very tempted to propose a syntax for an opt-in kdbus-like security model (which would take precedence over system.conf/system.d) via adding lines to .service files, so that individual services can have a sane security model on non-kdbus or non-Linux systems, and systemd's systemd-dbus1-generator could use those lines as input. If we get far enough with moving system services to that, maybe the transition can be easier. Session bus access-control policy = In principle, people could configure the session bus to do the same elaborate access-control as the system bus. In practice, this is not a particularly useful thing to do, because there are many ways for processes running under the same uid to subvert each other, particularly if a LSM like SELinux or AppArmor is not used. kdbus does not appear to make any attempt to protect a uid from itself: the uid that created a bus is considered to be privileged on that bus. I assume this means that the intention is that app sandboxing will use a separate Unix uid, like it does on Android? Unless there's an outcry from people who like LSMs, I'm inclined to say that protecting same-uid session processes from each other is doomed to failure, and hence that it's OK for DBUS_BUS_SESSION to connect to kdbus without special precautions. Resource limits === Some resource limits are lower in kdbus than in dbus-daemon. In kdbus, the number of unread messages per recipient is limited to 256, with up to 16 per uid; subsequent broadcasts are silently dropped, and subsequent unicast messages cause the sender to block. The message header (fixed-length header and header fields) is limited to 2 MiB in kdbus, whereas on dbus-daemon it may be up to a configurable limit, by default 32 MiB for the system bus or 128 MiB for the session bus. Broadcast messages (header + body) have the same 2 MiB limit, but unicast message bodies
Re: [systemd-devel] Compatibility between D-Bus and kdbus
Hi Simon, On 10/01/2014 03:33 PM, Simon McVittie wrote: (Cc'd to the systemd mailing list because sd-bus is the reference implementation of the user-space side of kdbus, but please join the dbus list and follow-up there if you are interested in D-Bus.) I've recently been looking at kdbus as a transport for D-Bus messages, and how compatible or otherwise it is with traditional stream-based D-Bus (and in particular, dbus-daemon, the reference implementation of stream-based D-Bus). My intention here is to replace dbus-daemon on Linux with something that does not have dbus-daemon's limitations, but avoid making existing software non-functional or insecure in the process. See https://bugs.freedesktop.org/show_bug.cgi?id=84188 for my attempts to document the current state of kdbus in the D-Bus Specification. Thanks a lot for doing this! Much appreciated. I have not reviewed quality-of-implementation except where I happened to notice things as I went past, and I have not yet looked at Samsung/Tizen's patches adding a kdbus transport to libdbus and GDBus; for now I'm using sd-bus as my only reference for the user-space parts. Let me just state that we didn't post kernel patches to the D-Bus list in the past, as we didn't intend to discuss the internals of the kernel code on primarily user-space mailing lists. That, of course, doesn't mean we didn't want to discuss the external userspace API. We absolutely want to make sure that kdbus is capable of serving as transportation level interface that allows us to implement the same set of features that we have now, eventually, and it seems like a good time to get into the details. While in the past, we were saying that kdbus is not ready yet and people should not yet look at it closely, we're now at a stage in which we consider the interface more or less stable. Some internal details might still change, however. So, for everyone interested, please have a look at the following git repository: https://code.google.com/p/d-bus/ There's a fairly comprehensive documentation in kdbus.txt on the public kernel API, which is itself defined in kdbus.h. If you have any questions that are not answered by the existing documentation, please feel free to ask. We also accept patches, of course. Since a long time, it's also possible to boot up machines with systemd when --enable-kdbus is passed in configure, the module is built and installed, and the verb 'kdbus' is added to the kernel command line. System bus access-control policy I think this is the biggest point of incompatibility. In dbus-daemon there is a needlessly elaborate access-control language; in kdbus, there is a much simpler and more realistic access-control language, which specifically does not look into message payloads. Exactly. In contrast to the traditional dbus-daemon, the transport layer in kdbus has no understanding of what it actually transports in its data blobs. There's no code in the kernel that is able to marshal or demarshal the payload, that's entirely left to the users and the libraries they use. This is far easier to reason about than what dbus-daemon does, but it's a problem for any system service that assumes that its existing per-interface or per-method access-control will be applied, such as Avahi denying access to SetHostName. It is not acceptable for such services to get instant security flaws as a result of their D-Bus implementation being upgraded from a version that does not support kdbus to a version that does. Unfortunately, last time we discussed this, we didn't have a particularly good solution. Yes, that needs to be addressed. However, we won't add support to kdbus for method filtering or anything alike, so the kernel won't be able to help enforce such policies. If I remember correctly, the least bad solution anyone could think of was to introduce a new pseudo-bus-type alongside DBUS_BUS_SYSTEM (and its equivalent in other libraries like GDBus), perhaps called DBUS_BUS_SYSTEM_UNTRUSTED or something (better names welcome), with its own shared connection: connections to that bus type are not assumed to filter messages by their payload, and method-call recipients are expected to use Polkit or similar, or do their own simplistic access-controls like must be uid 0 by calling GetConnectionUnixUser or GetConnectionCredentials on the sender's unique name. On non-kdbus systems, it would just be the same thing as DBUS_BUS_SYSTEM; on kdbus systems, DBUS_BUS_SYSTEM would refuse to use the kdbus transport, and fall back to stream-based D-Bus compatibility mechanisms like systemd-bus-proxyd. That would enable individual libraries and applications to opt-in to using this new shared connection when they have been audited for safety, with the goal being that everything eventually moved to it, and nothing connected to DBUS_BUS_SYSTEM any more. Exactly, we would fall back to legacy translators for such client.
Re: [systemd-devel] Compatibility between D-Bus and kdbus
On Wed, 01.10.14 14:33, Simon McVittie (simon.mcvit...@collabora.co.uk) wrote: Thanks a ton for reviewing kdbus and its concepts! (Also, sorry for not responding earlier to all the dbus/kdbus traffic in the last month, I was travelling.) System bus access-control policy I think this is the biggest point of incompatibility. In dbus-daemon there is a needlessly elaborate access-control language; in kdbus, there is a much simpler and more realistic access-control language, which specifically does not look into message payloads. This is far easier to reason about than what dbus-daemon does, but it's a problem for any system service that assumes that its existing per-interface or per-method access-control will be applied, such as Avahi denying access to SetHostName. It is not acceptable for such services to get instant security flaws as a result of their D-Bus implementation being upgraded from a version that does not support kdbus to a version that does. Unfortunately, last time we discussed this, we didn't have a particularly good solution. If I remember correctly, the least bad solution anyone could think of was to introduce a new pseudo-bus-type alongside DBUS_BUS_SYSTEM (and its equivalent in other libraries like GDBus), perhaps called DBUS_BUS_SYSTEM_UNTRUSTED or something (better names welcome), with its own shared connection: connections to that bus type are not assumed to filter messages by their payload, and method-call recipients are expected to use Polkit or similar, or do their own simplistic access-controls like must be uid 0 by calling GetConnectionUnixUser or GetConnectionCredentials on the sender's unique name. Yes, this is indeed the solution I have in mind, and I think Ryan is mostly OK with this too for GLib. On non-kdbus systems, it would just be the same thing as DBUS_BUS_SYSTEM; on kdbus systems, DBUS_BUS_SYSTEM would refuse to use the kdbus transport, and fall back to stream-based D-Bus compatibility mechanisms like systemd-bus-proxyd. That would enable individual libraries and applications to opt-in to using this new shared connection when they have been audited for safety, with the goal being that everything eventually moved to it, and nothing connected to DBUS_BUS_SYSTEM any more. I'm also very tempted to propose a syntax for an opt-in kdbus-like security model (which would take precedence over system.conf/system.d) via adding lines to .service files, so that individual services can have a sane security model on non-kdbus or non-Linux systems, and systemd's systemd-dbus1-generator could use those lines as input. If we get far enough with moving system services to that, maybe the transition can be easier. If packages want compatibility with both kdbus/systemd and classic dbus1, then I'd suggest to simply continue shipping the old XML policy file fragments, plus the new systemd .busname unit. On dbus1 systems the old policy would be used, on new kdbus systems the new policy would be used. The app would of course be updated to use the new bus name to connect to to acknowledge that it is responsible for doing auth on its own. In this scheme compatbility should be easy: just add the new stuff on top, and leave the old stuff in place, and things should be good. No need to add anything new that would be a stop-gap and little else. Session bus access-control policy = In principle, people could configure the session bus to do the same elaborate access-control as the system bus. In practice, this is not a particularly useful thing to do, because there are many ways for processes running under the same uid to subvert each other, particularly if a LSM like SELinux or AppArmor is not used. Yes, Linux access control is built around UIDs, GIDs and labels, and I am pretty strongly of the idea that we should do access control based on exactly these credentials, but not come up with new access control schemes betweend processes, that does not run along these lines. kdbus does not appear to make any attempt to protect a uid from itself: the uid that created a bus is considered to be privileged on that bus. I assume this means that the intention is that app sandboxing will use a separate Unix uid, like it does on Android? Well, our idea about sandboxing for apps that it is mostly about visibility, not just mere access control. Or in other words: if a sandboxed app shall not be able to manipulate other processes then these processes should not be visible to it at all (via PID namespacing). Similar, if it is not supposed to be able to manipulate per-user kernel settings, then this should also be solved by visibility (via user namespacing) and so on. For kdbus this translates to the custom endpoint logic, where you can add additional bus device nodes for existing busses, that carry a second, stricter policy that is applied on top of the main bus policy. This allows us to
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On Sun, 21.09.14 15:31, Martin Steigerwald (mar...@lichtvoll.de) wrote: I just have one question. In the light of [...] in the light of the ongoing discussions on linux-kernel, debian-devel, debian- user and other mailing lists more than some dozens threads meanwhile: Did you ever ask yourself why your project provokes that amount of resistance and polarity? Did you ever ask yourself whether this really is just resistance against anything new from people who just do not like new or whether it contains *valuable* and *important* feedback? That's already two questions... But anyway. Let me turn your question around: we swapped out one of the most central pieces of Linux systems, one of the pieces that is probably the most core of what administrators interface with every day. How could this change ever have gone *without* any noise? Administrators probably are a generally more conservative bunch, anything that interferes with their day-to-day workflow that they are used to is a distraction. That's quite understandable. In fact, I used to be an admin myself a long time ago, and I still administer a couple of machines. I have similar feelings when I update them, and in particular when some component I don't want to spend the time to relearn changes I end up being annoyed (dovecot config file changes!). Moreover, init systems are just an auxiliary tool to run things. Nobody starts a computer up to run systemd on it. People start up a computer to run a web app or database server software on it. Because of that, systemd is just a tool to make something else work, and the focus is always on that other thing, and any time spent on systemd or relearning it feels like wasted time to many. I totally and absolutely understand these feelings. However, I also believe that the change we are making is for the good, and even though it might not be obvious to many immediately, it brings major benefits when administering machines, and they massively outweigh the disadvantage of changing things. And apparently I am not entirely alone with this, as the folks who make technical decision for the various distributions ended up deciding in favour of systemd in most cases. Yes, we knew exactly we'd be getting a lot of heat for all this. We have been getting it from the day on we announced the project. And I am pretty sure it will continue this way for a while still. (What I didn't expect though is how awful the Linux community can actually be. That people collect Bitcoins to hire a hitman on me, that people start petitions to make me stop working, and all that other really hateful, personal stuff is really apalling. I guess I have a thick skin, because I don't care too much, but jeezus christ, it's really disgusting sometimes.) I monitor the feedback posted on the Internet regularly. I browse reddit and the debian and gentoo mailing list archives sometimes, and try to distill the useful bits out of all the noise and hate dumped there. This actually used to be very productive for quite some time, and much of the polishing that systemd got over the years was a result of the feedback I read through this way, even if I had to read between the lines of all the hateful mails. Today, it's much less useful, I figure partially because the worst usability issues with systemd have long been fixed, but also because the crowd commenting changed from folks who were genuinely interested (early adopter folks) to a more general audience which also includes a lot of haters. The current increase noised level around systemd adoption I attribute to three things: the fact that RHEL7 is out now, the fact that due to the adoption of systemd as default by Debian and Ubuntu the folks who ignored the discussion so far now are faced with this change, and also to a big part to certain columnists who in the interest of generating traffic to their sites try to create a hubbub out of very little. Anyway, long story short: we knew what we did, and yeah, I read feedback, even if it is written in a hateful style, and we learn from it. For now I use systemd. I like quite some features. But on the other hand I am vary about it myself. I look at a 45 KiB binary for /sbin/init as PID1 and a 1,3 MiB binary in systemd 215 and wonder myself. I see systemd --user processes running and wonder: Well, note that systemd used for user services actually saves you resources, as the systemd binary only needs to be mapped into memory once and then is shared between all user instances and the system instance. Is it really all just nay-sayers for the sake of nay-saying? No, it's not that simple. Or do they – at least partly – provide *valuable* and *important* feedback. Well, some is valuable and important, but much certainly isn't. The 200nd complaint that systemd was monolithic or so is something I am genuinely not interested in anymore, for example... I will continue to scan reddit and the mailing list archives for stuff I find, but of
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On Mon, 22.09.14 10:16, Dale R. Worley (wor...@alum.mit.edu) wrote: 1. Systemd has some very large binaries, each of which implements many aspects of the system. Conversely, the typical Un*x approach is to separate functions into many executablels, many of which are scripts. The latter approach makes customization easier, especially for sysadmins who aren't deeply familiar with the system. We split up things into 80+ binaries. 2. Systemd includes a tremendous number of features and behaviors, but a lot of them aren't documented very well. That's not so unusual in Un*x, but if you're introducing something new, nobody has any prior knowledge of it, and the lack of documentation becomes visible. Please let us know where documentation is missing. I know a couple of areas where documentation is lacking (such as the too muc hof the C APIs we expose currently), but at least the user-facing stuff should be pretty comprehesively documented. If you are missing docs for something I'd be quite interested to know for which parts so that we can actually fix it. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On Tue, 23.09.14 15:13, Dale R. Worley (wor...@alum.mit.edu) wrote: Again, this seems rather ignorant of the status quo. Between the blog posts and wiki documentation and the 164 man pages, systemd is rather copiously documented. Not to say that things can't be improved, but by Linux standards we are at least making an effort. Bugs for missing or unclear documentation and usually handled, and any patches for documentation are applied fairly quickly. OK, I'd like to modify systemd's handling of mounts. I've been told only that the units that are created from /etc/fstab are created and handled by the main systemd binary. What documentation do I look at that explains how systemd actually does that, what the relevant source is, etc.? With init scripts, I know it's somewhere in a script in /etc/rc.d/init.d; searching for mount probably reveals a couple of hundred lines of shell script within which the functionality is hiding. As mentioned on this thread systemctl help on a unit is a really easy way to get more information about it. Pretty much all units we ship with systemd upstream contains the necessary meta information to link it up directly with its docs. mount units for /etc/fstab entries are nowadays generated from a so called generator, see systemd-fstab-generator(8). Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] logind: add support for TPS65217 Power Button
On Sat, 27.09.14 09:55, Koen Kooi (k...@dominion.thruhere.net) wrote:
diff --git a/src/login/70-power-switch.rules b/src/login/70-power-switch.rules
index a6997f7..695d246 100644
--- a/src/login/70-power-switch.rules
+++ b/src/login/70-power-switch.rules
@@ -10,5 +10,6 @@ ACTION==remove, GOTO=power_switch_end
SUBSYSTEM==input, KERNEL==event*, SUBSYSTEMS==acpi, TAG+=power-switch
SUBSYSTEM==input, KERNEL==event*, KERNELS==thinkpad_acpi,
TAG+=power-switch
SUBSYSTEM==input, KERNEL==event*, ATTRS{name}==twl4030_pwrbutton,
TAG+=power-switch
+SUBSYSTEM==input, KERNEL==event*, ATTRS{name}==tps65217_pwr_but,
TAG+=power-switch
If the input masking kernel patch David did won't get applied anytime
soon it might be worth moving these tags to the hwdb, so that we don't
have to list tons of devices explicitly here.
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] nss-mymachines and virtual machines
On Fri, 26.09.14 12:23, Simon Peeters (peeters.si...@gmail.com) wrote: hej, In the light of my linux classes i was looking into hooking up vagrant with machined in order to be able to use nss-mymachines to resolve the ip address on the host-only adaptor. Unfortunatly the network side of machined seems to only work with containers (since afaik it looks for a veth pair). It doesn't actually care about veth. The NSS module talks to machined, and machined will actually enter the network namespace of the container and query the network configuration in there. It would be nice to enable this also for virtual machines (in this case virtualbox). we could: * allow the ip and optionally interface to be specified on machine creation. + ensures nobody can change it once the machine is running - would require yet another create dbus call We already have a second evrsion that additionally takes an interface index. I have never added it to the wiki docs though. The nss module uses this to initially the ipv6 scope id sockaddr field so that that link-local ipv6 addresses work correctly with the NSS module. * add the ip and interface as writable properties. + less code, easy to use. - allows any system process (not only the supervisor of the machine) to modify this information at runtime. Any ideas on this? I'd like to open this up so that we can automatically resolve names for local VMs and UML machines. However, I don't think static passing of IP addresses to machined will work. IP configuration is inherently dynamic these days, and if we'd allow this the configuration could easily get out of sync. One great advantage of the the scheme currently implemented for containers is that it never gets out-of-sync. The NSS module always returns the exact IP configuration of the container, for whatever that might be. One thing I'd like to do instead is hook up networkd's dhcp registry with NSS in some way. i.e. all local VMs/UML machines that acquired an IP address via DHCP from the host would be implicitly resolvable. Of course, this would only work for DHCP systems, but I have the suspicion that that's pretty much covers the vast majority of VM/UML setups. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Why working this on reboot but not on start up
On Tue, Sep 30, 2014 at 9:24 PM, Günther J. g...@gjn.priv.at wrote: Hello, Am Dienstag, 30. September 2014, 20:38:10 schrieb Andrei Borzenkov: В Tue, 30 Sep 2014 13:24:13 +0200 Günther J. Niederwimmer g...@gjn.priv.at пишет: Hello, I have a problem to run this correct, it is working on a reboot but not on start up. What does not work means exactly? Bette I say it works sometime but the most of the Time not Can any help me for this Problem, Thanks. Without clear explanation what working and what not working is? Unlikely. I have a 0/SUCCESS in the status but I have no Principal I'm confused. You mean - you have no ticket for principal, or that TGT replies that your principal does not exist? I make a new service File for the kerberos initialisation this is my construct is any wrong in this files? /etc/tmpfiles.d/kinit.conf d /run/user/0/krb5cc 1777 root root - /etc/systemd/system/kinit.service [Unit] Description=Kerberos initial kinit Wants=SuSEfirewall2_setup.service Why Kerberos initialization *wants* firewall? I can understand After, but I have hard time to understand Wants here. The kerberos Server is on a other System (KVM Client) OK I delete the Wants ;) and change After=network.target After=SuSEfirewall2_setup.service [Service] Type=simple Do you really mean it? I'd rather expect oneshot here. I have a systemd Error with oneshot Well, in both cases it looks like kinit fails to obtain a ticket. So this is the real problem you need to debug. systemd can assist here by capturing output of kinit for further analysis, but that's probably all. Try asking kerberos guys how to enable verbose debugging of kinit. ExecStart=/usr/bin/kinit -k host/asmtp.gjn.prv Restart=on-failure RestartSec=30 [Install] WantedBy=multi-user.target /etc/systemd/system/kinit.timer [Unit] Description=Fist Initialisation of KRB5 [Timer] OnBootSec=3min [Install] WantedBy=timers.target Why do you need to start it two times - once as normal service and second time as timer? Normal, I like to start only with timer service. -- mit freundlichen Grüßen / best Regards, Günther J. Niederwimmer ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Cannot get Shutdown Script to Run (Libvirt Virtual Machine Shutdown)
Thanks for the reply :) The libvirt-guests.service was the very first thing I had tried. It, however, did absolutely nothing and I believe it to be broken in arch linux. I have given up on trying to get a shutdown/reboot script to run for now. On Tue, Sep 23, 2014 at 5:44 AM, Daniel P. Berrange berra...@redhat.com wrote: On Sun, Sep 21, 2014 at 11:40:03PM -0400, Alexander Groleau wrote: Hello systemd users, I have been trying desperately for weeks to get my simple shutdown script for a Libvirt guest to run before libvirtd is shut down, without success. Essentially, I need the libvirt-windows.sh script to run before the libvirtd service is terminated (which occurs right after systemd-logind outputs its reboot message). How can I get my script into this initial section of daemon shutdowns, at the top? Any reason you've created your own shutdown script instead of using the libvirt-guests.service script that libvirt includes ? To get the ordering right, we have a number of rules: - libvirtd.service contains Before=libvirt-guests.service - libvirt-guests.service contains After=libvirtd.service - The guest scope unit contain After=libvirtd.service and Before=libvirt-guests.service It was the two rules aginst the .scope units that we found to be the key part to making shutdown work, whereby guests get stopped gracefully before the libvirtd daemon is stopped. The .scope units do not have any file on disk, they are generated on the fly as libvirt talks to systemd-machined, so you've no way to alter them to work with your custom shutdown script. Thus if you are not using the standard libvirt-guests.service, then you should at least use the name libvirt-guests.service for your own custom service. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/2] PORTING-DBUS1: we use :1.%llu not :0.%llu for D-Bus unique bus names
--- src/libsystemd/sd-bus/PORTING-DBUS1 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/libsystemd/sd-bus/PORTING-DBUS1 b/src/libsystemd/sd-bus/PORTING-DBUS1 index 958e7b6..81e9413 100644 --- a/src/libsystemd/sd-bus/PORTING-DBUS1 +++ b/src/libsystemd/sd-bus/PORTING-DBUS1 @@ -66,7 +66,7 @@ fields as you need. The kernel will return in the id field your unique id. This is a simple numeric value. For compatibility with classic dbus1 simply -format this as string and prefix :0.. +format this as string and prefix :1.. The kernel will also return the bloom filter size and bloom filter hash function number used for the signal broadcast bloom filter (see -- 2.1.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/2] sd-bus: use terms from the D-Bus Specification a bit more
D-Bus' type hierarchy as described in the spec is: \- basic \- fixed type (u, i, etc.) \- string-like type (s, o, g) \- container Someone seems to have referred to basic types as simple types at some point, but that term isn't defined in the D-Bus Specification, and seems redundant. So far I haven't renamed functions that use trivial in their names to mean fixed type, to avoid confusion about whether a struct of constant length, like (iu), is a fixed type. The answer is that it is fixed-length, but is not a fixed type, so I can see that something like bus_type_is_fixed() might be ambiguous. --- src/libsystemd/sd-bus/PORTING-DBUS1 | 10 +- src/libsystemd/sd-bus/bus-type.h| 2 ++ 2 files changed, 7 insertions(+), 5 deletions(-) diff --git a/src/libsystemd/sd-bus/PORTING-DBUS1 b/src/libsystemd/sd-bus/PORTING-DBUS1 index 9f0a91d..958e7b6 100644 --- a/src/libsystemd/sd-bus/PORTING-DBUS1 +++ b/src/libsystemd/sd-bus/PORTING-DBUS1 @@ -156,11 +156,11 @@ multiple items. Some restrictions apply however: contained in the payload, as well is immediately before framing of a Gvariant, as well after as any padding bytes if there are any. The padding bytes must be wholly contained in the preceding - PAYLOAD_VEC/PAYLOAD_MEMFD item. You may not split up simple types - nor arrays of trivial types. The latter is necessary to allow APIs - to return direct pointers to linear chunks of fixed size trivial - arrays. Examples: The simple types u, s, t have to be in the - same payload item. The array of simple types ay, ai have to be + PAYLOAD_VEC/PAYLOAD_MEMFD item. You may not split up basic types + nor arrays of fixed types. The latter is necessary to allow APIs + to return direct pointers to linear arrays of numeric + values. Examples: The basic types u, s, t have to be in the + same payload item. The array of fixed types ay, ai have to be fully in contained in the same payload item. For an array as or a(si) the only restriction however is to keep each string individually in an uninterrupted item, to keep the framing of each diff --git a/src/libsystemd/sd-bus/bus-type.h b/src/libsystemd/sd-bus/bus-type.h index 2e423bb..581e8d5 100644 --- a/src/libsystemd/sd-bus/bus-type.h +++ b/src/libsystemd/sd-bus/bus-type.h @@ -29,6 +29,8 @@ bool bus_type_is_valid(char c) _const_; bool bus_type_is_valid_in_signature(char c) _const_; bool bus_type_is_basic(char c) _const_; +/* trivial is systemd's term for what the D-Bus Specification calls + * a fixed type: that is, a basic type of fixed length */ bool bus_type_is_trivial(char c) _const_; bool bus_type_is_container(char c) _const_; -- 2.1.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] nss-mymachines and virtual machines
On Thu, Oct 2, 2014 at 12:58 AM, Lennart Poettering lenn...@poettering.net wrote: On Fri, 26.09.14 12:23, Simon Peeters (peeters.si...@gmail.com) wrote: hej, In the light of my linux classes i was looking into hooking up vagrant with machined in order to be able to use nss-mymachines to resolve the ip address on the host-only adaptor. Unfortunatly the network side of machined seems to only work with containers (since afaik it looks for a veth pair). It doesn't actually care about veth. The NSS module talks to machined, and machined will actually enter the network namespace of the container and query the network configuration in there. It would be nice to enable this also for virtual machines (in this case virtualbox). we could: * allow the ip and optionally interface to be specified on machine creation. + ensures nobody can change it once the machine is running - would require yet another create dbus call We already have a second evrsion that additionally takes an interface index. I have never added it to the wiki docs though. The nss module uses this to initially the ipv6 scope id sockaddr field so that that link-local ipv6 addresses work correctly with the NSS module. * add the ip and interface as writable properties. + less code, easy to use. - allows any system process (not only the supervisor of the machine) to modify this information at runtime. Any ideas on this? I'd like to open this up so that we can automatically resolve names for local VMs and UML machines. However, I don't think static passing of IP addresses to machined will work. IP configuration is inherently dynamic these days, and if we'd allow this the configuration could easily get out of sync. One great advantage of the the scheme currently implemented for containers is that it never gets out-of-sync. The NSS module always returns the exact IP configuration of the container, for whatever that might be. One thing I'd like to do instead is hook up networkd's dhcp registry with NSS in some way. i.e. all local VMs/UML machines that acquired an IP address via DHCP from the host would be implicitly resolvable. Of course, this would only work for DHCP systems, but I have the suspicion that that's pretty much covers the vast majority of VM/UML setups. Yeah, adding a sd-network api to query the DHCP leases we have handed out makes sense. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [question] networkd: Any support for hooks?
Hello, ifupdown [1], NetworkManager, and WICD all support hooks for when a network interface is configured or deconfigured (before and after these actions). Are there any plans to support something along these lines? If so, what will that look like? If there are no plans, how do networkd's developers feel about adding the feature (will not merge, or will accept patches, etc.) ? Thank you, [1] Debian's networking service, re-implemented a couple times elsewhere (busybox, and some other independent stuff) -- Cameron Norman ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [question] networkd: Any support for hooks?
Hi Cameron, On Thu, Oct 2, 2014 at 6:36 AM, Cameron Norman camerontnor...@gmail.com wrote: ifupdown [1], NetworkManager, and WICD all support hooks for when a network interface is configured or deconfigured (before and after these actions). Are there any plans to support something along these lines? If so, what will that look like? If there are no plans, how do networkd's developers feel about adding the feature (will not merge, or will accept patches, etc.) ? I am sceptical to adding hooks, so would need a lot of convincing. What we do, however, is to expose the configuration state using the sd-network C API, which external programs can watch and react on (see how timesyncd and resolved currently works). For specific hooks, we may want to integrate them directly upstream, but it really depends on what functionality you have in mind. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
