Re: standardize uid:gid?
On Thu, 18 Jan 2024 13:40:01 +0100, Greg Wooledge wrote: > On Thu, Jan 18, 2024 at 05:38:37AM -0000, David Chmelik wrote: >> Couldn't Debian standardize uid:gid numbers for daemons? >[...] * Every obscure, niche package's users and groups would have to be >added to every Debian system. I don't even think we *know* how many >this would be. Hundreds? Thousands? Do you want a thousand new >system users to be created in your /etc/passwd file? Your local UIDs >beginning with 1000 might be overwritten. [...] I doubt; way SlackBuilds.org (SBo) does (though 'unofficial'... recent years, after endorsement/usage by Slackware creator, seems quasi-official) is each user/uid & group/gid is added with its software, so one certainly doesn't need to add any until installed. However, if potentially will be installed, still should be standardized and installed with each particular package. Usually these start after system users/uids & groups/gids before 100 and go on to before 1,000 (but clearly don't overwrite that). If truly necessary for some bizarre/illogical reason to install users/uids & groups/gids one doesn't even use, perhaps one could have master/reference passwd & group files (or reference document like http://slackbuilds.org/ uid_gid.txt ) and ones of only what's installed, to make things easier for system administrators (sysadmins). Clearly it would be bad for passwd & group files to become like Ubuntu snapd debacle/fiasco in which if you install 1,000 snap packages (snaps) then type 'mount' you get over 1,000 entries so 'mount' command becomes unusable. A workstation/server usually isn't a phone PC (with snaps) and a Debian computer isn't likely ever a server that'll have all daemon/etc. (I don't know it's just daemons?) users/uids & groups/gids, rather than only some/many, which brings the question what's the point of installing all even if standardized? >They might have to be rebased to start at 3000, or 5000. Would that >be high enough? Would it be future-proof? [...] SBo currently only uses uid:gid between (not all) 81 and 382, but if Debian does differently or has more, one might need keep ones already used from 43 to 999 (some seem standardized as said, but not all) and then continue above some high number you mentioned I have no idea if high enough or 'future-proof'... no telling what might be high enough for servers with large/increasing number of users. It'd need expert consideration but, as you say, maybe are too many uids:gids for feasibility. I guess difference is despite Slackware has largest base system, it has fewer extra/installable packages, so doesn't have same problem of potentially thousands to standardize. Extra/SBo (whether unofficial or quasi-official) software only has recommended standard, despite I see SBo similar to Debian's repositories, so theoretically possible but might be more work than feasible. I'll read about solutions people posted above for installing/ standardizing Debian-based workstations/servers with same users/uids & groups/gids ahead of time, and I suppose this might work with GUI-based derivatives I administer for users, not just my Debian servers? I first saw replies on nntp:linux.debian.user but wasn't allowed to reply there so am trying nntp:gmane.nntp:linux.debian.user ... sorry if the above shows up twice...
standardize uid:gid?
Couldn't Debian standardize uid:gid numbers for daemons? The oldest--and only strictly UNIX-like--GNU/Linux (Slackware) does this so if you install multiple instances and want them the same, you can backup /etc/passwd & / etc/group from one and use them on another (as long as there aren't different users which is sometimes the case). This standardization was probably from UNIX/*BSD. What happens every time I can't use *BSD or Slackware on a server and resort to Devuan (or Debian-based for some users' PCs) is that all the uid:gid seem random so there's no way to administer them all with the same files in cases that it'd work. Having random uid:gid is a last-rate style.
os-prober detects in wrong order and GRUB doesn't have enough options
Earlier this or last year I tried to use Devuan to report os-prober detects in wrong order. It may detect current OS partition first, but if you have more than 10, then it continues from 10, and (if this is all you have) goes to the last in the tens but then continues somewhere in single- digit partitions, so then puts your OS all in wrong order in GRUB2, which should have more options about menu order like is easy to configure LILO exactly the way you want. I have some entries I wrote myself, because even after a bug report over 10 years ago, os-prober didn't detect FreeBSD & NetBSD (reported) & DragonFlyBSD UNIXes, nor OpenSolaris/IllumOS UNIXes, nor does GRUB2 do some GNU/Linux right like SystemRescue and some obscure boot options some RedHat variants need or won't boot. Seems like the bug maybe didn't get reported to the os-prober programmers. Did it not get through or is there another way I could report this?
dictd?
How can I add a dictionary (I have dictionary.dict.gz & dictionary.index) to dictd? Apparently doesn't work same as on *BSD UNIX & Slackware GNU/ Linux...
Re: disable GUI/X?
On Tue, 18 Jun 2024 22:39:15 -0400, Felix Miata wrote: > David Chmelik composed on 2024-06-19 02:24 (UTC): > >> How can I disable GUI/X for next boot? I just want to run it when I >> decide as startx/startxfce/etc. > > # systemctl get-default # reports bootup state # systemctl set-default > graphical.target sets GUI as default state # systemctl set-default > multi-user.target brings system up without GUI running > > For a single boot to finish at multi-user, simply append 3 to the end of > the (usually wrapped) linu line after striking E key at the default Grub > menu selection. If already using multi-user.target default, append 5 to > linu line to get a full GUI boot. What about in the case I use SysVInit so don't have systemctl?
dictd
How can I add a dictionary (I have dictionary.dict.gz & dictionary.index) to dictd?
disable GUI/X?
How can I disable GUI/X for next boot? I just want to run it when I decide as startx/startxfce/etc.
Re: disable GUI/X?
On Wed, 19 Jun 2024 08:47:58 +0200, tomas wrote: > On Wed, Jun 19, 2024 at 04:39:50AM -0000, David Chmelik wrote: >> On Tue, 18 Jun 2024 22:39:15 -0400, Felix Miata wrote: >> > David Chmelik composed on 2024-06-19 02:24 (UTC): >> > >> >> How can I disable GUI/X for next boot? I just want to run it when I >> >> decide as startx/startxfce/etc. >> > >> > # systemctl get-default [...] > >> What about in the case I use SysVInit so don't have systemctl? > > Then you have an /etc/init.d/xdm (or gdm, or..., depending on your > display manager). I know... and? Set them non-executable like in /etc/rc* on older OS? > And, if you don't feel like managing it manually, you have update-rc.d, > which comes with a manual page. [...] I prefer manually, but if multiple steps, am interested in update-rc.d.
Re: disable GUI/X?
On Wed, 19 Jun 2024 01:06:04 -0400, Felix Miata wrote: > David Chmelik composed on 2024-06-19 04:39 (UTC): >> On Tue, 18 Jun 2024 22:39:15 -0400, Felix Miata wrote: >>> David Chmelik composed on 2024-06-19 02:24 (UTC): >>>> How can I disable GUI/X for next boot? I just want to run it when I >>>> decide as startx/startxfce/etc. >>> >>> # systemctl get-default # reports bootup state # systemctl set-default >>> graphical.target sets GUI as default state # systemctl set-default >>> multi-user.target brings system up without GUI running >>> >>> For a single boot to finish at multi-user, simply append 3 to the end >>> of the (usually wrapped) linu line after striking E key at the default >>> Grub menu selection. If already using multi-user.target default, >>> append 5 to linu line to get a full GUI boot. > >> What about in the case I use SysVInit so don't have systemctl? > > One way, rather extreme but effective, would be to find a distribution > neither systemd nor Debian based. I used them more than 5/9 my life (since 1997): *BSD UNIX & Slackware GNU/ Linux (also Debian sometime 1998-2002, and since 2020 on servers that only run inside OpenVZ) but desktop broke so am temporarily using family spare (not reinstalling... not powerful enough to do much extra... generally not building software/packages, and users don't want operating systems even more difficult when returned). Of course, these older ones are superior due to being strictly UNIX[-like]. I know, but doesn't help meantime. > Many have or had more than Debian's two sustaining runlevels. E.g. > Fedora, Mageia and openSUSE and those much like them before systemd > existed are where those numbers 3 & 5 came from. Whereas in Debian there > were only 1/S and 2 for sustaining runlevels, for simply single and > everything, the others had more granularity: RedHat/Fedora is originator of systemd and those use it, which none originated runlevels. Debian is older than all those. > Slackware uses 4 instead of 5 but otherwise is the same, and still > focused on SysV. That's what I wish I could've set in Debian. > I never did learn any easy way to do as requested in Debian prior to > systemd. I didn't use it much then either. For me, systemd has mostly > been an advantage over SysV tradition. Hasn't for me: a mess (could do paragraph rant why but maybe pointless). Debian documentation says SysVInit is still mostly 'supported'.
Re: disable GUI/X?
On Tue, 18 Jun 2024 22:54:00 -0400, Greg Wooledge wrote: > On Tue, Jun 18, 2024 at 22:39:15 -0400, Felix Miata wrote: >> David Chmelik composed on 2024-06-19 02:24 (UTC): >> > How can I disable GUI/X for next boot? I just want to run it when I >> > decide as startx/startxfce/etc. >> >> # systemctl get-default # reports bootup state # systemctl set-default >> graphical.target sets GUI as default state # systemctl set-default >> multi-user.target brings system up without GUI running >> >> For a single boot to finish at multi-user, simply append 3 to the end >> of the (usually wrapped) linu line after striking E key at the default >> Grub menu selection. If already using multi-user.target default, append >> 5 to linu line to get a full GUI boot. > > Or if you *never* want to use a graphical display manager for login, > just remove the display manager package, whichever one it is. I don't, but except for few days/weeks, won't be the only person using this desktop... that's why I said 'disable' rather than 'remove'.
Re: dictd?
On Wed, 19 Jun 2024 10:29:58 +0500, Stanislav Vlasov wrote: > ср, 19 июн. 2024 г. в 06:53, David Chmelik : >> How can I add a dictionary (I have dictionary.dict.gz & >> dictionary.index) >> to dictd? Apparently doesn't work same as on *BSD UNIX & Slackware >> GNU/ Linux... > > man dictd: >/usr/share/dictd > The default directory for dictd databases (.index and > .dict[.dz] files) > > Place files to /usr/share/dictd and run `dictdconfig -w` and restart > dictd service Thanks! I guess it doesn't work with symbolic links (symlinks) to user directories/folders though... I used to enter my own directories in db.list instead of being forced to put everything there and generate that.
