You are not logged in.
Mmm, I give you that; though I do think your first post could be way less alarmist, if that was your intention.
No, turnstile does not "handle login sessions". It gets notified about login and logout happening, and then it runs (or terminates) user scripts qua the user (not as root). I think it'd be much less of a hacker's attraction than, say, dbus, since turnstile is very well contained in what it does.
But for sure, there are many other ways for users to run programs, and there is no real need for a system to have a turnstile daemon to manage running them with "session control". I agree on that aspect ![]()
EDIT: btw, which thread title would you set?
Too much writing so it got it's own thread.
It is also the case that nothing what you raise as criticism has any value. Just very opiniated.
Turnstile does achive the notion of "user services" without comromising on security.
If you are the admin of your system, you don't need to use it, Use something else.
Yes, I wouldn't have mentioned it otherwise.
In my experience the packaged turnstile daemon is quite stable and safe. The package default backend, despite its name "suss", also works quite well. (I haven't explored the other backends) It provides a reliable "user service" process control including both one-shot actions and session-based services.
The expected "normal" use is straight-foward. A user that wants many services with start-up inter-dependencies may of course need to design that start-up somewhat carefully.
In short: a good option.
Ah, so you just repeated a phrase from the upstream README.
I read your post as if you knew about something particular.
Refering to source would best be https://git.devuan.org/devuan/turnstile as it then would include patches and packaging deployed for the Devuan (and proposed Debian) package.
(Done by Mark Hindley and myself)
@igorzwx: I don't understand what you mean with that "warning"? Have you been using it and ran into issues?
Nothng to worry about.
TL;DR; The initial boot sequence includes a filesystem check of the root filesystem, and that results in a log file which at that time resides in RAM. Then the scripting for some reason gets confused when trying to store the log on disk. I'm guessing the script writer failed to consider the range of possible boot-up scenrios so ended up making the script lodging a spurious notice instead.
Yes that should be fine.
As far as I know, the only possible caveat in that would be if the USB stick was of a kind that doesn't allow block 0 to be updated. But it's very unusual to run into those nowadays. To be really sure about that you would need to copy back the USB content to the size of the ISO into another file, and then compare that with the ISO (e.g. by using shasums).
I have no idea what Rufus is or does. But I know that the ISO is made for being copied verbatim onto the disk media from block 0 and up. Perhaps you could find and try with using "DD for Windows" instead?
It sounds like you are using a legacy bios boot on a disk image file. That boot equipment variant does require that the boot partition is marked as bootable, which appears no to be the case for you.
Note that Devuan experimantal also includes turnstile which also is in the NEW queue for a Debian build.
Standalone login/session tracker
aims to serve as a fully featured alternative to the logind subproject from systemd, and to provide a neutral API to both our session tracker and to logind itself. Currently it offers:
- session/login tracker
- a service-manager-agnostic way to manage per-user service managers for user services
When multiple entries match for a user, they are applied in order. Where there are multiple matches, the last match is used (which is not necessarily the most specific match).
In your case it looks like
%sudo ALL=(ALL:ALL) ALLis the last matching entry, at least when the shutdown user is in the sudo group.
Please stop arguing about yourselves and now focus on the OP issue again.
Not at all. Gentoo is fine. People using Gentoo are fine. Do that with Gentoo resources.
This forum is intended for Devuan focus.
Why the hell should you discuss gentoo here???
Don't they have a forum that is good enough or something???
Off topic babble seems to be the menu of the day. I could delete but I'm not too comfortable doing that.
Do we have someone standing up to take on maintainer role? You can email me.
Yes send me the link so I can learn.
I'm sure Gentoo and Arch both have their forum. Maybe your could move to there?
@exponentialmatrix: I'm sorry for all those irrelevant posts on this thread.
You are quite welcome to setup your "Devuan User Repository" on git.devuan.org using the means provided. I know you would like the "user organisations" feature, and if that is a show stopper for you, then it's understandable that you can't use the Devuan's git store.
One avenue for inducing change to Devuan's setup could be to engage with other people than just me. For example, you could take part in the weekly (video) meetings, and in there try to push for the particular changes you want to see. Though it probably will take engagement effort and that you maintain your community oriented spirit.
... Plus perhaps that you reflect on your position regarding organisational shrouding on the git store so as to be able to explain it to us at least how your case is different (and especially not a way to avoid or reduce personal responsibility). We are all just people, with a range of different understandings and opinions, and your views will matter as well.
@steve_v: Are you volunteering?
@exponentialmatrix: perhaps my suggestion doesn't fit your purpose.
I suppose it's obvious I don't know what AUR is or how it's used, but off hand I see no compelling argument against the principle setup to have a single "DUR project" to house the ~150 thingies, beside the one or a few infrastructrual projects. But I can also understand how that setup thought might not gel too well with your vision.
But I need to leave this for tonight, though; in fact it's already tomorrow here ![]()
Yes, Devuan's git store doesn't have "user organisations" enabled.
The git store is only intended for users keeping and sharing their "source code".
Though, obviously life is full of change. Perhaps you (or someone) will make a sufficiently compelling argument that organisational shrouding is a necessary or at least significantly useful feature for this purpose, and so make us re-open that discussion about its enabling.
But there is no formal vetting here, about the software a user keeps and shares; merely the ordinary care-taking spot reviews that rests heavily on community feedback as means of maintaning relevance and quality.
It may be less than known and understood, but in fact almost anyone may register at git.devuan.org and use it as repository for their public projects. If it's aimed at sharing, then documentation is essential.
When you have a binary package to publish you may drop in at #devuan-dev (at libera.chat) to discuss how that may happen; although first and foremost of course you'd publish your package to Debian. Though in some cases it may be warranted to have a trial publishing at Devuan/experimental.
you need to add a parameter to qemu so that it attaches its "monitor" to either a socket that you can connect to, OR as multiplexed with the serial console.
For the first option, you add the qemu command line arguments -monitor unix:QEMU,server,nowait, and thereby get its monitor serving the socket QEMU in the working directory. You then connect to that via socat with a command like the following
socat -,escape=0x1c,rawer unix:QEMUwhich sets up a raw termnal connection to that monitor; you break the connection with key ctrl-\ (control-backslash).
For the second option you instead modify (or add) serial line arguments to be -serial mon:stdio, and thereby get multiplexed monitor and serial console on the run terminal. In that case it starts in serial mode so you need to press ctrl-a c to switch to the qemu monitor.
Then, once you have the monitor, you will issue the commands like sendkey ctrl-alt-f2 etc so as to make the monitor send that key.
hth