Re: [systemd-devel] Upstreaming systemd patch
On Thu, Jul 30, 2020 at 8:51 AM Amit anand wrote: > Hi, > > Not able to create pull request to systemd, permission denied to my github > user credentials. > > I git cloned https://github.com/systemd/systemd > > While creating pull request, > git push --set-upstream origin > 1. Entered github username > 2. Entered github passwd > getting below error message for my github username. > remote: Permission to systemd/systemd.git denied to > fatal : unable to access 'https://github.com/systemd/systemd.git/': The > requested URL returned error: 403 > Pull requests are usually made from your own personal repository. Use Github's "Fork" feature to get a writable copy of the repository, then `git remote add` its URL and push there. For example: git remote add fork https://github.com//systemd git push -u fork -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] 246 rc2 : stdio-bridge: failed to process bus
On Mi, 29.07.20 17:25, Dac Override (dac.overr...@gmail.com) wrote: > Since 246 i can't get -H to work anymore. It returns empty and on the > host it logs > > Jul 29 17:18:05 agnus systemd-stdio-bridge[227915]: Failed to process > bus: Operation not permitted > > PS: systemd-anaalyze completion does not cover log-level Could you please file github issues about both issues? (And ideally provide an strace of the stdio bridge thing?) https://github.com/systemd/systemd/issues/new?template=Bug_report.md Thank you! Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Creating a fake logind seat with no devices [Experiment]
On Wednesday, July 29, 2020 7:13:23 AM EDT Lennart Poettering wrote: > On Mi, 29.07.20 00:11, nerdopolis (bluescreen_aven...@verizon.net) wrote: > > > Hi > > > > Sorry about the length. > > > > I have a unique thing I am trying to solve, is that if I have a service > > that calls /sbin/logind under > > something like tmux, and I set `Environment=XDG_SEAT=seat0` in the service > > file, upon logging in, > > pam_systemd fails to create a session, as it's seat0 and it's expecting a > > valid TTY number, as it's > > seat0. One of the side effects is that you lose the credential prompt that > > you usually get if you > > run a command like `systemctl restart foo.service`, and there could be > > other things too? > > Seats are a concept of grouping hardware. A seat without hardware > is pointless. If you have no hardware associated with a session then > the session is seat-less, which is totally fine. > > I don't get what you are trying to do? > > Lennart > > -- > Lennart Poettering, Berlin > Hi I am pretty much trying to cobble together tmux, cage, and vte, to create a full screen VT-like console lookalike. (as the kernel one takes input from all devices from all seats on a multiseat system). Mostly experimental. (tmux server/client being used to avoid having to start vte and cage as root for /sbin/login) The problem is that the tmux PTY running /sbin/login , those sessions don't properly create a full pam_systemd sessions on seat0, as I get "VT number out of range", because as I understand seat0 sessions need to be on a valid TTY. Non-seat0 seats don't have this restriction, but non-seat0 seat hardware is far from a guarantee However I will note so far the only major side effect I notice to not having (sd-pam) started in this session is, for instance `pkexec` won't work, without sudo. And systemctl doesn't try to use PolicyKit and whatnot, as from what I understand, that needs to be on a session assigned to a seat to work I think Thanks ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd 246 released
A new, official systemd release has just been tagged . Please download the tarball here: https://github.com/systemd/systemd/archive/v246.tar.gz Changes since the previous release: * The service manager gained basic support for cgroup v2 freezer. Units can now be suspended or resumed either using new systemctl verbs, freeze and thaw respectively, or via D-Bus. * PID 1 may now automatically load pre-compiled AppArmor policies from /etc/apparmor/earlypolicy during early boot. * The CPUAffinity= setting in service unit files now supports a new special value "numa" that causes the CPU affinity masked to be set based on the NUMA mask. * systemd will now log about all left-over processes remaining in a unit when the unit is stopped. It will now warn about services using KillMode=none, as this is generally an unsafe thing to make use of. * Two new unit file settings ConditionPathIsEncrypted=/AssertPathIsEncrypted= have been added. They may be used to check whether a specific file system path resides on a block device that is encrypted on the block level (i.e. using dm-crypt/LUKS). * Another pair of new settings ConditionEnvironment=/AssertEnvironment= has been added that may be used for simple environment checks. This is particularly useful when passing in environment variables from a container manager (or from PAM in case of the systemd --user instance). * .service unit files now accept a new setting CoredumpFilter= which allows configuration of the memory sections coredumps of the service's processes shall include. * .mount units gained a new ReadWriteOnly= boolean option. If set it will not be attempted to mount a file system read-only if mounting in read-write mode doesn't succeed. An option x-systemd.rw-only is available in /etc/fstab to control the same. * .socket units gained a new boolean setting PassPacketInfo=. If enabled, the kernel will attach additional per-packet metadata to all packets read from the socket, as an ancillary message. This controls the IP_PKTINFO, IPV6_RECVPKTINFO, NETLINK_PKTINFO socket options, depending on socket type. * .service units gained a new setting RootHash= which may be used to specify the root hash for verity enabled disk images which are specified in RootImage=. RootVerity= may be used to specify a path to the Verity data matching a RootImage= file system. (The latter is only useful for images that do not contain the Verity data embedded into the same image that carries a GPT partition table following the Discoverable Partition Specification). Similarly, systemd-nspawn gained a new switch --verity-data= that takes a path to a file with the verity data of the disk image supplied in --image=, if the image doesn't contain the verity data itself. * .service units gained a new setting RootHashSignature= which takes either a base64 encoded PKCS#7 signature of the root hash specified with RootHash=, or a path to a file to read the signature from. This allows validation of the root hash against public keys available in the kernel keyring, and is only supported on recent kernels (>= 5.4)/libcryptsetup (>= 2.30). A similar switch has been added to systemd-nspawn and systemd-dissect (--root-hash-sig=). Support for this mechanism has also been added to systemd-veritysetup. * .service unit files gained two new options TimeoutStartFailureMode=/TimeoutStopFailureMode= that may be used to tune behaviour if a start or stop timeout is hit, i.e. whether to terminate the service with SIGTERM, SIGABRT or SIGKILL. * Most options in systemd that accept hexadecimal values prefixed with 0x in additional to the usual decimal notation now also support octal notation when the 0o prefix is used and binary notation if the 0b prefix is used. * Various command line parameters and configuration file settings that configure key or certificate files now optionally take paths to AF_UNIX sockets in the file system. If configured that way a stream connection is made to the socket and the required data read from it. This is a simple and natural extension to the existing regular file logic, and permits other software to provide keys or certificates via simple IPC services, for example when unencrypted storage on disk is not desired. Specifically, systemd-networkd's Wireguard and MACSEC key file settings as well as
