Re: [systemd-devel] Systemd daemon access permissions

[Mantas Mikulėnas]

On Fri, Feb 5, 2016 at 2:43 AM, Zamar Ac  wrote:

> Hello guys,
>
> Upon system boot I'm not gettings active network. The log says:
>
> "systemd-networkd[246]: Could not connect to bus: Permission denied"
>
> I'm trying to log more details, but again hitting the same issue despite
> logged in as root upon boot. Why root access is denied to the bus?
>
> "# SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd
> name_to_handle_at on /dev: Permission denied
> the udev service seems not to be active, disable the monitor
> Could not connect to bus: Permission denied"
>

Do you use SELinux, Smack, AppArmor, grsec?
What are the permissions of /run/dbus/system_bus_socket?
Does commenting out the CapabilityBoundingSet= option help?


>
> OK, as a workaround I manually modified
> /usr/lib/systemd/system/systemd-networkd.service instead, adding:
>
> "[Service]
> ...
> Environment=SYSTEMD_LOG_LEVEL=debug"
>
> but apparently don't see more details about the problem in system log
> after reboot. Why? Generally, with what permissions systemd daemons like
> networkd run at boot? Do they have root permissions? If not, can I assign
> them root permissions, and how?
>
> Another approach - looking for workarounds. Lets entirely bypass this
> systemd process until fixed in the future, since I need a working system
> right now. What config settings would allow to auto enable network after
> boot without networkd daemon running?
>

Depends on your distro – if you're not using systemd-networkd, then it's no
longer systemd's business.

For example, Debian has ifupdown (man interfaces) and Gentoo has netifrc.
If there's no distro-specific system, then NetworkManager 1.x would do the
job.

-- 
Mantas Mikulėnas 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Proposal: Add biosdevname naming scheme to systemd

[Lukáš Nykrýn]

Jordan Hargrave píše v Čt 04. 02. 2016 v 13:24 -0600:
> 
> 
> On Tue, Oct 20, 2015 at 10:04 PM, Jordan Hargrave 
> wrote:
> > On Tue, Oct 20, 2015 at 3:02 PM, Andrei Borzenkov <
> > arvidj...@gmail.com> wrote:
> > > 20.10.2015 17:30, Jordan Hargrave пишет:
> > >
> > >> On Tue, Oct 20, 2015 at 1:15 AM, Andrei Borzenkov <
> > arvidj...@gmail.com>
> > >> wrote:
> > >>>
> > >>> On Tue, Oct 20, 2015 at 7:46 AM, Jordan Hargrave <
> > jhar...@gmail.com>
> > >>> wrote:
> > 
> >  On Mon, Mar 2, 2015 at 1:17 PM, Tom Gundersen 
> > wrote:
> > >
> > > Hi Jordan,
> > >
> > > On Mon, Mar 2, 2015 at 4:45 PM, Jordan Hargrave <
> > jhar...@gmail.com>
> > > wrote:
> > >>
> > >> There are currently two competing naming mechanisms for
> > network cards,
> > >> biosdevname and systemd.  Systemd currently has some
> > limitations on
> > >> naming
> > >> cards that use network partitioning or support SR-IOV.
> > >
> > >
> > > Could you point to an example so we can fix it? I thought all
> > bug
> > > reports had been handled, but maybe I lost track of
> > something.
> > >
> > 
> >  I have a quad-port NIC:
> >  :40:00.0 = PCIE bridge (SMBIOS Slot 2)
> >  :41:00.0 = Ethernet Device (port1)
> >  :41:00.1 = Ethernet Device (port2)
> >  :42:00.0 = Ethernet Device (port3)
> >  :42:00.1 = Ethernet Device (port4)
> > 
> >  biosdevname would name these p2p1, p2p2, p2p3, p2p4
> > respectively.
> > 
> > >>>
> > >>> How does it determine that 41 and 42 are the same device? I.e.
> > how
> > >>> does it differ from real bridge with two independent two-port
> > cards
> > >>> behind? Could you explain what information it is using? Is it
> > exported
> > >>> in sysfs?
> > >>>
> > >>> ...
> > >>
> > >>
> > >> It knows they are on the same slot as the parent device has
> > SMBIOS
> > >> Slot#2 (Type 9).  So all child devices of a physical slot are on
> > the
> > >> same card.  I'm currently using a patch to systemd that reads
> > SMBIOS
> > >> type 9.  There isn't a kernel sysfs variable that displays this.
> > >>
> > >
> > > This gives us slot ID, but how do we know which of function 0 on
> > this slot
> > > ID is port 0 and which is port 2? There is nothing in SMBIOS
> > description of
> > > Type 9 that answers it.
> > 
> > 
> Looking for a resolution for this.. adding port numbers to systemd
> enumeration of devices in PCI slots.
> 
> Systemd still doesn't have the concept of a 'Port' number, so multi
> -port NICs get named with enpsf instead of
> ensp.
> 
> There needs to be a way to generate systemd names that have the
> following variables for add-in cards:
>   Slot Number
>   Port Number
>   Instance Number (for SR-IOV or Network Partitioned devices)
> 
> It is possible to calculate the port number without any knowledge of
> sibling devices.  Requires knowledge of device PCI ID, parent tree
> and 'dev_port' attribute (for mellanox cards). Then the devices could
> be named ensSLOTpPORT

Aren't we already doing that with:

s[f][d] -- hotplug slot index number

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel