Re: [systemd-devel] [PATCH] Added UFD (Uplink failure detection) support to networkd
HI, While reading this I'm just thinking about RFC5880 ff. BFD support. Anybody in the networks universe already thinking about this? Holger - On 23 Jan, 2015, at 18:20, Alin Rauta alin.ra...@intel.com wrote: Hi, Uplink Failure Detection (UFD) is a key enhancement to networkd, that will provide support for the switch use case. The links can be configured as uplinks or as downlinks inside an UFD group. When all uplinks for a group are down, the failure is propagated to the downlinks, so the devices connected to them can take a defined action. When at least one uplink become available, the daemon tries to bring the downlink ports up. Multiple UFD groups can be configured through .netdev files. See below a configuration example: [NetDev] Name=group1 Kind=ufd [UFDGroup] Id=10 [UFDLink] Name=sw0p1,sw0p2 Type=uplink [UFDLink] Name=sw0p3 Type=downlink [UFDLink] Name=sw0p4 Type=downlink Few details on implementation: Networkd waits until all links are enumerated (either static configured or unmanaged). Only then it starts enumerating the groups. networkctl command was also updated to support listing of ufd groups configuration. See below a print-out: # networkctl ufd 10 ? UFD Group: 10 Config File: /etc/systemd/network/ufd_to_test.netdev State: configured Uplinks: ? 3: sw0p1 ? 4: sw0p2 Downlinks: ? 6: sw0p4 ? 5: sw0p3 Please let me know what you think. Thanks, Alin Alin Rauta (1): Added Uplink failure detection feature to networkd Makefile.am |4 + man/systemd.netdev.xml | 72 +- src/libsystemd/sd-network/sd-network.c | 117 +++ src/network/networkctl.c| 153 src/network/networkd-link.c | 35 + src/network/networkd-manager.c | 36 + src/network/networkd-netdev-gperf.gperf |3 + src/network/networkd-netdev-ufd-group.c | 298 +++ src/network/networkd-netdev-ufd-group.h | 85 ++ src/network/networkd-netdev.c | 36 + src/network/networkd-netdev.h |6 + src/network/networkd-ufd-daemon.c | 1321 +++ src/network/networkd-ufd-daemon.h | 34 + src/network/networkd.c |7 + src/network/networkd.h |6 + src/systemd/sd-network.h| 20 + 16 files changed, 2231 insertions(+), 2 deletions(-) create mode 100644 src/network/networkd-netdev-ufd-group.c create mode 100644 src/network/networkd-netdev-ufd-group.h create mode 100644 src/network/networkd-ufd-daemon.c create mode 100644 src/network/networkd-ufd-daemon.h -- 1.9.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Holger Winkelmann ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] journald syslog forwarding
Hi, sorry for delay in reply.. Journal carries messages from the initramfs. We cannot send them from the initramfs, unless we bring up the network then, which we don't want to do just for this purpose. But those messages are stored in /run/log, and then flushed to /var/log, and the uploader tool can forward them after the network is established. Right but I thought that might be controlled via socket and once the network would become available it would dump the content of the socket buffer on the wire... Please advise me If Im wrong, but I can't see how can control a sending socket with with a .socket unit. Can you make an example? Many thanks, Holger JBG -- Holger Winkelmann email: holger.winkelm...@travelping.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] journald syslog forwarding
HI, Our embedded distribution relies on the systemd tooles including journal based logging. However there is a need to forward log messages to remote syslog. We try to avoid to introduce a full blown syslog solution like i.e. rsyslog to just forward log messages to a remote syslog server. Is there any plan to have a journal2syslog gateway in the sense of the HTTP gateway? BR, -- Holger Winkelmann email: holger.winkelm...@travelping.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] journald syslog forwarding
Hi, However there is a need to forward log messages to remote syslog. We try to avoid to introduce a full blown syslog solution like i.e. rsyslog to just forward log messages to a remote syslog server. What Jóhann describes should work, even though it is a bit hacky. There is also a TODO item to add the functionality to send syslog packets over the network to either systemd-journald or a different tool. As we have worked on a ZeroMQ Journal gateway [1], which is a bit more advanced like the HTTP gateway and allows to query the journal apart of just forwarding, we could imagine to contribute to this work. As well of i.e. adding native GELF [2] forwarding to a Graylog2 server. Are there any plans to follow? I.e, having all protocols in a generic gateway, or having one gateways per protocol? How the should we define which field form the journal should be forwarded to syslog? Zbyszek Does adding systemd.journald.forward_to_kmsg= ( or configure it in journald.conf via ForwardToKMsg=yes ) netconsole=[src-port]@[src-ip]/[],[tgt-port]@/[tgt-macaddr] on the kernel command line work for you? [1] https://github.com/travelping/zmq-journal-gatewayd [2] https://www.graylog2.org/resources/gelf -- Holger Winkelmann email: holger.winkelm...@travelping.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] journald syslog forwarding
HI, Are there any plans to follow? I.e, having all protocols in a generic gateway, or having one gateways per protocol? How the should we define which field form the journal should be forwarded to syslog? IIUC, Lennart wanted to add this funcitonality to systemd-journal-upload or a new tool. I think it might be nicer to add it directly to systemd-journald, even though it would then use the network. The details are fuzzy atm. upload sounds a bit of a batch process, but thats just cosmetic wording. Having this in systems-journald and extend the forward to syslog config with the target host was our expectation anyway. Initial plan was to implement the most straighforward syslog forwarding, so only the MESSAGE field would be sent. it would be great to have at least the following format to send to syslog: %pri%%protocol-version% %timestamp:::date-rfc3339% %HOSTNAME% %app-name% %procid% %msg%\n described as rsyslog configuration. All the meta infos are there IMHO. I think that additional forwarders (e.g. GELF) should stay as separate projects. I think so as well. Zbyszek -- Holger Winkelmann email: holger.winkelm...@travelping.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] journald syslog forwarding
Hi, upload sounds a bit of a batch process, but thats just cosmetic wording. Having this in systems-journald and extend the forward to syslog config with the target host was our expectation anyway. The difference is in how the logs are accessed: if journald itself does the jobs, they would be forwarded live. If anything else, the uploader would be a client which reads the files in /var/log/journal/. The are advantages to both solutions: the first one might be more robust if writing the logs fails or stops for whatever reason. The second one will probably send more logs, because sending of logs can be delayed until the network is up. In the second version, the uploader can also forward logs from other machines (containers). Now that I spelled it out, the second version seems nicer. I agree with your findings, and basically thats how the zmq journal gateway works as well. And thanks to bring the wait for network up here, you would miss important boot log entries here. Would the upload tool learn a new URL for this purpose i.e. syslog://ip:514 ? Initial plan was to implement the most straighforward syslog forwarding, so only the MESSAGE field would be sent. it would be great to have at least the following format to send to syslog: %pri%%protocol-version% %timestamp:::date-rfc3339% %HOSTNAME% %app-name% %procid% %msg%\n described as rsyslog configuration. All the meta infos are there IMHO. Yes. We just wouldn't go into structured syslog messages to carry other fields. I agreed as well mapping then into the struct syslog format wold be a config pain I assume. However the one we listed above should be there ?!?!... If people correlating syslog messages on a central server, time, hostname etc. are meaningful. Holger -- Holger Winkelmann email: holger.winkelm...@travelping.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] journald syslog forwarding
HI, Would the upload tool learn a new URL for this purpose i.e. syslog://ip:514 ? Or a broadcast address, so no configuration is required. Hmmm. Admin guys would not really like broadcast here. But anyway would not argue much if it can be configured. Initial plan was to implement the most straighforward syslog forwarding, so only the MESSAGE field would be sent. it would be great to have at least the following format to send to syslog: %pri%%protocol-version% %timestamp:::date-rfc3339% %HOSTNAME% %app-name% %procid% %msg%\n described as rsyslog configuration. All the meta infos are there IMHO. Yes. We just wouldn't go into structured syslog messages to carry other fields. I agreed as well mapping then into the struct syslog format wold be a config pain I assume. However the one we listed above should be there ?!?!... That's rfc5424, right? Then yes. Yes, it is -- Holger Winkelmann email: holger.winkelm...@travelping.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] journald syslog forwarding
HI, Or a broadcast address, so no configuration is required. I'd really like to see broadcast delivery I must say. as mentioned, why not if it can switched off and unicasted to the IP:514 That's rfc5424, right? Then yes. Is that RFC actually widely adopted? I'd stay as conservative as possible with all of this. Ooops, sorry, wrong RFC. I think 3164 is the right one. RFC 5324 obsoletes RFC 3164, but if it comes to the format of the messages most of the resources point back to RFC3164, so both is slightly right. in reply to Lennart, at least I know a couple of people correlating and sorting messages based on the format mentioned above. As already said I would be conservative either and not try to put all the structure in structured syslog. but adding the few Meta data to the syslog message would help. Holger -- Holger Winkelmann email: holger.winkelm...@travelping.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] journald syslog forwarding
I'm not quite following what you said there but I would actually think the former as in forward it live is better, ju Journal carries messages from the initramfs. We cannot send them from the initramfs, unless we bring up the network then, which we don't want to do just for this purpose. But those messages are stored in /run/log, and then flushed to /var/log, and the uploader tool can forward them after the network is established. Right but I thought that might be controlled via socket and once the network would become available it would dump the content of the socket buffer on the wire... I was thinking about the same, but what about the size Limitation? Is there not a long standing issue that the socket buffer size is global and not per socket? I remember a discussion around one of the plumbers conference? Anyway what abut a two fold approach? the journal learns plain live forwarding to a remote host or even broadcast. and the messages can be forwarded once the network is available. If socket controlled works you may win a few more messages but you never know you get all messages from boot. This is current behavior of remote syslog forwarding I assume. If you want more there could be a independent tool works like the systems-journal-gatewayd or systemd-journal-uplaod and can be started later once network available. This will read the log and forward all messages from the current boot and following. Holger -- Holger Winkelmann email: holger.winkelm...@travelping.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFT] DHCPv4 support in networkd
just a small off topic question here. How far is IPv6 support in networks incl. DHCPv6? Many thanks and a happy new year! Holger -- Holger Winkelmann ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] remote journal enhancements
Hi By writing distributed applications we will look further for log aggregation in the style of the systems-journal-gateway. Regarding this I would like to know about the idea and plans of the systemd community. Following the emails about logger optimization Lennart mentioned something about kdbus transports for logging (on kdbus systems) further systemd has usually dubs APIs for introspection but the journal is access directly by journalctl and the corresponding C-API. Yes, that's not going to change. Kdbus might be used for *sending* messages, because it makes sends metadata about the sender and removes the need for the (very slow and racy) querying of process attributes through /proc. OTOH *reading* is going to stay independent of journald. In some cases that would be even impossible, e.g. when journald is running within a container, and we are looking at the logs from outside. Thats would be my view as well, but wanted to make sure we are on the right track. Sending and reading are two different things. Are there any plans/ideas to give the journald a D-Bus/kdbus API for querying the journal? Or should reading/querying the journal totally decoupled from journald in a daemon like systems-journal-gateway? If we work on a separate journal-gateway do you have any ideas/requirement about the API this should expose, again like D-Bus for local communication and i.e. HTTP, JSON-RPC, AMQP etc. for remote communication? Should we include any access control which honors the underlying journal fils ACLs or should we have ACLs for given fields on the journal? Not directly related, but I intend to dig out my send-messages-over-http [1] patches and adapt them to sd-event and resend during the christmas break. means to send a message over HTTP which ends up in the journal, basically the counterpart of systems-journal.gatewayd? What do think is the best transport representation for remote logging: a) keep the binary (hopefully compact and fine for sending over binary protocols) b) use the EXPORT format (seems plain text based?) c) JSON (great HTTP I assume) Holger Zbyszek [1] http://lists.freedesktop.org/archives/systemd-devel/2012-November/007427.html -- Holger Winkelmann Managing Director email: h...@travelping.com phone: +49-391-819099-223 mobil: +49-171-5594745 http://www.linkedin.com/in/hwinkel - enabling your networks - Travelping GmbH phone: +49-391-8190990 Roentgenstr. 13 fax: +49-391-819099299 D-39108 Magdeburg email: i...@travelping.com GERMANY web: http://www.travelping.com Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 Geschaeftsfuehrer: Holger Winkelmann | VAT ID No.: DE236673780 -- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Erlang binding for Journal
Hi, We have just released the Erlang Binding ejournald [1] for the journal. It exposes the journal native API to log natively and query the journal. There is also a Erlang lager_journald_backend [2] which can be used for Erlang applications. [1] https://github.com/travelping/ejournald [2] https://github.com/travelping/lager_journald_backend -- Holger Winkelmann Managing Director email: h...@travelping.com phone: +49-391-819099-223 mobil: +49-171-5594745 http://www.linkedin.com/in/hwinkel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] remote journal enhancements
Hi David, - Original Message - On Wed, Dec 18, 2013 at 10:32 AM, Holger Winkelmann [TP] h...@travelping.com wrote: with HTTP you need to setup another server and provide a Call back URL Folks seem to increasingly call this pattern web hooks. I know, but i tried to avoid to use the webish terms on this list here... ;-) -- Holger Winkelmann Managing Director email: h...@travelping.com phone: +49-391-819099-223 mobil: +49-171-5594745 http://www.linkedin.com/in/hwinkel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] remote journal enhancements
Hi all, we are following the discussion initiated by Cecil about systemd journal for a while. The last couple of weeks we have developed a Erlang adapter for the journal to allow structured native logging. Therefore we have developed a ejournald [1] backend for the Erlang logging framework lager [2]. ejournald also got a Erlang wrapper to query the journal for log entries and emit messages for new arriving messages. By writing distributed applications we will look further for log aggregation in the style of the systems-journal-gateway. Regarding this I would like to know about the idea and plans of the systemd community. Following the emails about logger optimization Lennart mentioned something about kdbus transports for logging (on kdbus systems) further systemd has usually dubs APIs for introspection but the journal is access directly by journalctl and the corresponding C-API. Are there any plans/ideas to give the journald a D-Bus/kdbus API for querying the journal? Or should reading/querying the journal totally decoupled from journald in a daemon like systems-journal-gateway? If we work on a separate journal-gateway do you have any ideas/requirement about the API this should expose, again like D-Bus for local communication and i.e. HTTP, JSON-RPC, AMQP etc. for remote communication? Should we include any access control which honors the underlying journal fils ACLs or should we have ACLs for given fields on the journal? BTW: we know about use rsyslog answer but this was not the option here, wer looking for a lightweight gateway solutions like the gateway with some extended functionality. [1] @Mirjam, please provide the Repo at Github [2] https://github.com/basho/lager -- Holger Winkelmann Travelping email: h...@travelping.com phone: +49-391-819099-223 mobil: +49-171-5594745 http://www.linkedin.com/in/hwinkel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] journal: How to limit the file size of runtime system.journal
Hi, Is there any particular reason? I think thresold for runtime journal size can lower much because in initramfs it's not supposed to have much logs. First, there are some data strcutures which are allocated when the file is created, and if the file was very small, relatively more space would wasted. Second, repeated fields are not stored, just referenced, so things become more efficient when the file is not too small. But neither is fundamental reason, and with some tweaking the journal could be made to work much smaller files. I understand. These are really good points when logs are relatively large, ie. the journal is stored on a real disk. However when it's in initramfs context, journal is stored in tmpfs which is using the real memory resource as it's backend. 4 MB seems a little bit overkill especially when memory is quite limited case, like kdump. To be more specific, I think 512 KB or 1 MB is a fairly large enough nubmer when journal is stored to a volatile backend. We totally agree that a minimum size must be below 1MB either on flash or ramfs for embedded devices. otherwise you end up with two solutions for smaller and bigger devices. Is there any reference about the overhead if you use smaller file size? Is there technical limitation for a minimum size? Thanks, Holger Thanks WANG Chao ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Holger Winkelmann ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Logging in an enterprise environment
Hi Cecil, - Original Message - After giving a presentation about systemd/journald I am seen as the expert, so they come to me with the challenges they see. As I understand it, journald is mend to log locally. Two methods to log centrally are, if I have understand it correctly: - mounting and merging through NFS - systemd-journal-gateway Whereby the first would be the preferred method. The first will fail shorts if the Environment is distributed somehow, mounting NFS drives is not always a option. We prefer some gateway solution which forwards the log messages to a aggregation host. That would not be always acceptable for our clients. As I understood it there are environments where now 700+ systems are monitored from one log server. Using NFS for this would ask to much resources. I think that systemd-journal-gateway also would not be very handy for this because it is a pulling solution. We think of forwarding the messages when arrived locally. But we should think about local caching as well. What about the aggregator or network is not available? To make things even more complicated: sometimes they want no local logging at all, all logging should be done remotely, so that not one user on the system could read the logs. Would something like this be possible to implement? If so, how much work would it be? Probably our company would be prepared to let programmers write this functionality. My open question would be: If you aggregate the logs, with your example from 700 hosts, should we use the Journald Fileformat on the central location as well? Does it scale? should we write one journal file per host? can jpurnalctl deal with 7000 files and the huge content? Further we would like to discuss the transport between the host and the aggregator. many ideas come along like AMQP, pure TCP, Syslog(seems to limited), HTTP? Holger systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Holger Winkelmann email: h...@travelping.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] DBus signal on unit start/stop
Hi, - Original Message - On Saturday 30 November 2013 19:30:12 you wrote: There are standard dbus PropertiesChanged signals sent out for ActiveState changes, which invalidate the properties when they change in released versions of systemd, and which carry the new values along in git. We probably should document which ones we generate this for in http://www.freedesktop.org/wiki/Software/systemd/dbus/ Lennart Thanks for your reply. I have now been playing around with the PropertiesChanged signal and found it quite useful for getting updates from systemd. By hooking it up with a Qt slot I can update the UI on any unit changes. The only drawback is that I am not able to get information about which unit had its properties changed from the signal, so I have to update the entire list of units. However, this is much better than querying for unit changes at certain time intervals. If I read Lennart's answer correctly, the newer version in git already tells you what have changed: and which carry the new values along in git Is this right? -- Holger Winkelmann ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] DBus signal on unit start/stop
Hi Lennart, Thanks for pointing this out... There are standard dbus PropertiesChanged signals sent out for ActiveState changes, which invalidate the properties when they change in released versions of systemd, and which carry the new values along in git. We probably should document which ones we generate this for in http://www.freedesktop.org/wiki/Software/systemd/dbus/ I few lines of doc pointing in the right direction would be definitely helpful. Its always amazing whats already in systemd once you start asking... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Holger Winkelmann email: h...@travelping.com phone: +49-391-819099-223 mobil: +49-171-5594745 http://www.linkedin.com/in/hwinkel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd questions
Hi Dan, - Original Message - Hi, Having watched the discussion over the past week or so, I'm left with a few questions: 1) what is lacking in other userspace solutions (NetworkManager, ConnMan, wicked, initscripts, etc) that requires yet-another-network-daemon? 2) do you expect that systemd-networkd will grow to include bridge, bond, and team setup? how about other enterprise/server interface types like macvlan/vtap, tun/tap, gre, vxlan, ovs, etc? All these are enterprise things that typically won't change during a specific bootup, but which static servers increasingly use. If you don't expect these to be supported, why not? 3) Is there expected to be D-Bus interfaces for controlling or monitoring the network interfaces and configuration data? If not, why not? We asked our self the same questions, and alternatives exists even from the embedded camp [1] which often comes close to the server use case. Even if [1] does not have a Dbus interface, they at least share the same Idea of a RPC interface (Ubus) and have the building blocks for handling more complex interface setups like bridging, bonding, VLAN etc. We have worked with guys a lot but building a bridge between the embedded folks and the dbus camp is not so easy if it comes to small routers... But for my own records, what is so bad on the existing approach in [1]? anybody checked it while considering to develop systemd-networkd? [1] http://wiki.openwrt.org/doc/techref/netifd best regards, Holger Thanks, Dan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Holger Winkelmann Managing Director email: h...@travelping.com phone: +49-391-819099-223 mobil: +49-171-5594745 http://www.linkedin.com/in/hwinkel - enabling your networks - Travelping GmbH phone: +49-391-8190990 Roentgenstr. 13 fax: +49-391-819099299 D-39108 Magdeburg email: i...@travelping.com GERMANY web: http://www.travelping.com Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 Geschaeftsfuehrer: Holger Winkelmann | VAT ID No.: DE236673780 -- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd questions
sorry for double post after bounce and the huge signature, messed up my mail client config a bit.. Holger We asked our self the same questions, and alternatives exists even from the embedded camp [1] which often comes close to the server use case. Even if [1] does not have a Dbus interface, they at least share the same Idea of a RPC interface (Ubus) and have the building blocks for handling more complex interface setups like bridging, bonding, VLAN etc. We have worked with guys a lot but building a bridge between the embedded folks and the dbus camp is not so easy if it comes to small routers... But for my own records, what is so bad on the existing approach in [1]? anybody checked it while considering to develop systemd-networkd? [1] http://wiki.openwrt.org/doc/techref/netifd best regards, Holger Thanks, Dan ___ 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] [RFC][PATCH] networkd: add a basic network daemon
Hi, To clarify this: systemd-networkd is supposed to cover the initrd, container, server and (some) embedded usecases. However, use NM or connman for the interactive stuff (like wlans and suchlike) you need on laptops/desktops and mobile. Will this cover the UseCase of having a DHCP enabled Interface which starts asking for IP if the interface is coming up? or is this already considered as interactive uses case? in embedded this is often a standard configuration as such devices don't have a interactive interface and assigning a IP via DHCP makes the live much easier. currently we integrate http://0pointer.de/lennart/projects/ifplugd/ The idea is that this can work jointly with NM/connman in some ways or another. For example you can make use of .link files even with interfaces that otherwise are handled by connman/NM, but for IP config you have to chose one. Lennart -- Lennart Poettering, Red Hat -- Holger Winkelmann ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] networkd: add a basic network daemon
A native and fast DHCP client will be part of it, yes, it is needed in the initrd. Not sure though when we will get there though. nice to hear. and right, having it in initrd is nice too. currently we integrate http://0pointer.de/lennart/projects/ifplugd/ Urks, the 90s calling. :) Yes, embedded was so old style before... Kay -- Holger Winkelmann ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] networkd: add a basic network daemon
good morning,
We really like to see this direct, how ever would it not better to join
efforts for network management. I.e. arch Linux claims with netctl [1]
to do network management the systems way. and there are a few other
attempts to do network managent. I.e. netconfd [2] of openWRT is doing
network management (kind of monolitic) as a daemon as well which can
be configured via Bus RPC. (OK ubus in this case). Not to mention
the desktop centric network manager.
Can somebody explain the goals of systemd-networkd? If this just a small
basic tool will be replaced if more features are required or a new attempt
to for general network management?
[1] https://wiki.archlinux.org/index.php/netctl
https://github.com/joukewitteveen/netctl
[2] http://wiki.openwrt.org/doc/techref/netifd
BR,
Holger
- Original Message -
On Wed, 06.11.13 01:33, Tom Gundersen (t...@jklm.no) wrote:
Short-term TODO:
- make rtnl calls asynchronous
Don't wait for too long for this! The longer you wait the more code you
have to rework for this. And you shouldn't underestimate how complex
changes from sync to async are...
Gateway=192.168.1.1
Address=label@192.168.1.23/24
Address=fe80::9aee:94ff:fe3f:c618/64
Hmm, what's the plan regarding confguration of scopes and other
attributes of addresses? Is the label@ syntax your invention or has
this been used elsewhere (I am not opposed to the syntax, just curious).
+sd_event_add_io(m-event,
+udev_monitor_get_fd(m-udev_monitor),
+EPOLLIN,
+manager_dispatch_link_udev,
+(void *)m,
+m-udev_event_source);
Missing return value check! (and cast to void* is unnecessary, in C
all pointers automatically downgrade to void* without casting anyway)
+if (r 0) {
+log_warning(Colud not parse config file %s: %s,
filename, strerror(-r));
^^ Typo
+return r;
+} else
+log_debug(Parsed configuration file %s, filename);
+
+network-filename = strdup(filename);
OOM check missing!
+static void networks_free(Manager *manager) {
+Network *network, *network_next;
+
+if (!manager)
+return;
+
+LIST_FOREACH_SAFE(networks, network, network_next,
manager-networks) {
+network_free(network);
+}
I usually just use:
while ((network = manager-networks))
network_free(free);
Which should do the job too.
+struct Link {
+uint64_t ifindex;
Hmm is this really an uint64_t? if_nametoindex(3) suggestes it's an
unsigned?
But yeah, looks great. Commit.
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
Holger Winkelmann
Managing Director
email: h...@travelping.com
phone: +49-391-819099-223
mobil: +49-171-5594745
http://www.linkedin.com/in/hwinkel
- enabling your networks -
Travelping GmbH phone: +49-391-8190990
Roentgenstr. 13 fax: +49-391-819099299
D-39108 Magdeburg email: i...@travelping.com
GERMANY web: http://www.travelping.com
Company Registration: Amtsgericht Stendal Reg No.: HRB 10578
Geschaeftsfuehrer: Holger Winkelmann | VAT ID No.: DE236673780
--
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] bootchart issues on slow hardware
And make acceptance tests on such machines ;-) - Original Message - 'Twas brillig, and Kay Sievers at 18/03/13 10:42 did gyre and gimble: On Mon, Mar 18, 2013 at 5:06 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Sun, Mar 17, 2013 at 02:54:01PM +0100, Kay Sievers wrote: Here is a chart: http://people.freedesktop.org/~kay/bootchart-20130317-1434.svg Rotating media and really cheap hardware looks very sad, and we take like 5 times longer to boot than Windows 8. Why is systemd taking ~5 s, and udev 3 s of cpu time? Maybe there's something wrong here. Unfortunately it's hard to say what udev is waiting That's just the world of slow CPUs and rotating disks. Maybe developers should be forced to hack on such machines only. :) That's likely too cruel. Maybe just hack one day a week on such machines :) 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 -- Holger Winkelmann Managing Director email: h...@travelping.com phone: +49-391-819099-223 mobil: +49-171-5594745 (DE) - enabling your networks - Travelping GmbH phone: +49-391-8190990 Roentgenstr. 13 fax: +49-391-819099299 D-39108 Magdeburg email: i...@travelping.com GERMANY web: http://www.travelping.com Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 Geschaeftsfuehrer: Holger Winkelmann | VAT ID No.: DE236673780 -- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] bootchart issues on slow hardware
You are right, hopefully systemd will not turn into a direction where only the ulra modern notebook or desktop can use it. we see a lot of advantages to use systemd in embedded environments. and we are talking here about_ - 180-680 MHh MIPS, ARM CPUs - 4-32 MB Flash - 32-128MB RAM at the low end. Thos devices should be able to run systemd in the same way as other init systems. Holger - Original Message - On Mon, Mar 18, 2013 at 11:57 AM, Reindl Harald h.rei...@thelounge.net wrote: Am 18.03.2013 19:45, schrieb Kay Sievers: I put an SSD in that crappy box today; it's down from 25 to 7 sec on the otherwise identical system. :) So I'll not need to debug any rotating media issues, I don't have any of them again. :) this is nice for you but keep in mind that for professional environments for many years SSD is no option for some TB of data and even if the price falls down you have to calculate redundancy for RAID10 environemnts which can not be raplced by a SSD due lack of relieability and no real-world expierience how long they run and how you detect errors before it is too late I'm of the same mindset. For some time to come, many people will continue to purchase lower end systems without SSD's, and we want to offer them a compelling OS that outperforms the competitors in all aspects, including boot time. So, I consider the bad performance on non-SSD's a bug, and I'm looking at trying to find a solution. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Holger Winkelmann Managing Director email: h...@travelping.com phone: +49-391-819099-223 mobil: +49-171-5594745 (DE) - enabling your networks - Travelping GmbH phone: +49-391-8190990 Roentgenstr. 13 fax: +49-391-819099299 D-39108 Magdeburg email: i...@travelping.com GERMANY web: http://www.travelping.com Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 Geschaeftsfuehrer: Holger Winkelmann | VAT ID No.: DE236673780 -- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Hackfest] Room available in Avanti Hotel
Hi all, The room is gone... Holger - Original Message - Hi, One of our Guys is off sick and cant attend the Hackfest. So we have a room free in the Avanti Hotel from 21st - 22rd Feb. Anybody interested? Let me know the next hour please. BR, Holger -- Holger Winkelmann email: h...@travelping.com mobil: +49-171-5594745 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Holger Winkelmann Managing Director email: h...@travelping.com phone: +49-391-819099-223 mobil: +49-171-5594745 (DE) - enabling your networks - Travelping GmbH phone: +49-391-8190990 Roentgenstr. 13 fax: +49-391-819099299 D-39108 Magdeburg email: i...@travelping.com GERMANY web: http://www.travelping.com Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 Geschaeftsfuehrer: Holger Winkelmann | VAT ID No.: DE236673780 -- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd footprint
Hi Eduardo, Hi Holger, I think we have to blame the uninformed complaints that Systemd is only for the desktop because of Dbus. I was aware of this, but being a freedesktop project this not always feels server alike. Dbus can be built without X support. On Gimokod Linux the compressed package is at 240KB only. Thanks for that, this look not so bad, but raises another question i have in mind since reading about systems. Is a running dbus-deamon required to startup a system with systems? $ ldd /usr/bin/dbus-daemon linux-vdso.so.1 = (0x7fffcd3ff000) libexpat.so.1 = /lib/libexpat.so.1 (0x7f4317b7d000) libpthread.so.0 = /lib/libpthread.so.0 (0x7f4317963000) librt.so.1 = /lib/librt.so.1 (0x7f431775c000) libc.so.6 = /lib/libc.so.6 (0x7f431740f000) /lib/ld-linux-x86-64.so.2 (0x7f4317d9e000) See https://github.com/tongson/Gimokod/blob/f25a90aa8554149663ec768547987e44d5e4a1d7/core/dbus-core/PKGBUILD for the configure options used. checked Gimokod, looks nice as we having archlinux running here as well. Cheers. Thanks, Holger -- Holger Winkelmann Member of NGN Service Lab ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd footprint
On Dec 4, 2011, at 4:40 PM, Kay Sievers wrote: For very simple setups, the D-Bus bus daemon is not absolutely necessary, and can probably be made optional with a few changes, but the D-Bus protocol is used by systemctl to talk to systemd, and can not really be optimized out. systemctl talks directly to systemd via DBUS messages, or ONLY via dbus-deamon? We have not much problems with DBUS concept, DBUS message formats etc. But may we can scale it down to a minimum for embedded use. May transport DBUS messages over regular sockets, TIPC, NETLINK sockets or something like brokerless ZMQ. something does not require another deamon and becomes network transparent D-Bus is in not desktop centric, it's a plain IPC mechanism which lets processes talk to each other. It's just that the desktop is not as simple in its task as the usual base OS, so that it needs more advanced technology like IPC and an object model to let components integrate with each other Exatcly, thats what I mean, may we can remove some of the Desktop centric requirements and just use whats required in Server or embedded use cases. but keeping the vibrant ecosystem around DBUS and DBUS APIs. For server OSs, and any other commonly used setup, there will be no installation of systemd without D-Bus. It just can't work. Simple and limited embedded-like setups could work without the D-Bus server, but still not really without the D-Bus protocol. I agree. so lets call it eBUS a smaller DBUS use case, Kay Holger ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
