New OS request - NOT an ISSUE

[piranah]

Hi Team,

Very good work with FreeBSD stuff, just plain love it.

Is there a possibility to add support for OpenBSD 7.x in the future?

Would love to hear from you,

Reg,
p

[outpaddling]

I'd be happy to see support for other platforms, but I'm spread too thin already to do it myself.

The first step would be to add OpenBSD cases to all the relevant auto-admin scripts. "grep auto- NetBSD/desktop-installer" and get the auto-admin menu working on OpenBSD. That should cover most of it.

Second step would be writing the desktop-installer script for OpenBSD. I'd recommend the NetBSD script as a model, since it's much simpler than the FreeBSD script at this time.

[piranah]

Hi Jason, Thanks for getting back to me. What I am working on is a personal customization script I am writing for myself to help automate the laborious tasks one has to do after an OpenBSD installation like: 1. Adding the hostname to the /etc/hosts file 2. Enable trl+alt+bksp(zapping Xorg ) to break out of a W-windows session 3. Adding ~/.profile to the .xsession file 4. ...etc ... I think you get the idea ... I would have to look at the NetBSD scripts and see if I can make sense of it from a noobs-perspective ...Sure the OpenBSD and NetBSD scripts are very close, so the mods should be easy ?!? I am going to spend some time looking at the scripts. Reg, p

…

On Sat, Sep 23, 2023 at 11:44 PM Jason Bacon ***@***.***> wrote: I'd be happy to see support for other platforms, but I'm spread too thin already to do it myself. The first step would be to add OpenBSD cases to all the relevant auto-admin scripts. "grep auto-admin- NetBSD/desktop-installer" and get the auto-admin menu working on OpenBSD. That should cover most of it. Second step would be writing the desktop-installer script for OpenBSD. I'd recommend the NetBSD script as a model, since it's much simpler than the FreeBSD script at this time. — Reply to this email directly, view it on GitHub <#30 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGN6PRVX7DZZM6WPPQ5FD3X35J5PANCNFSM6AAAAAA5EM3UFA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[outpaddling]

The auto-admin scripts that require platform-specific code use case statements controlled by auto-ostype, a wrapper around uname mainly to distinguish Linux distros from each other (uname just reports "linux", which is useless in determining sysadmin commands, which are specific to the distro, not the kernel).

case $(auto-ostype) in
FreeBSD)
     # FreeBSD code
     ;;

RHEL)
     # Redhat Enerprise code
     ;;

esac

Where the necessary commands are exactly the same as a supported platform, it would be a simple matter of adding "or OpenBSD", e.g.

FreeBSD|OpenBSD)

In other cases, you would need to add a new OpenBSD case and write the appropriate code. The command below lists the auto-admin scripts run directly by the NetBSD version of desktop-installer. You can go through these one-by-one (recursively since they may run other auto-admin scripts) and add OpenBSD cases.

# grep --only-matching 'auto-[a-z\-]*' NetBSD/desktop-installer | sort | uniq
auto-admin
auto-append-line
auto-automount-setup          # Low priority, can be added later
auto-enable-service
auto-install-base-components  # Low priority, can be added later
auto-package-installed
auto-pkgsrc-wip-checkout    # Not really necessary for OpenBSD
auto-replace-file
auto-update-pkgsrc              # Not necessary for OpenBSD
auto-update-system

Only a fraction of auto-admin scripts are required by desktop-installer, directly or indirectly, so this task is not as daunting as one might assume at first. Just identify which scripts are required and pick them off one-by-one.

I would approach it top-down: Start writing the desktop-installer script, using the NetBSD version as a model, and when you reach a point where an auto-admin script is needed, add the OpenBSD case to it and test it by running your desktop-installer. This way, you'll make steady progress and have a well-tested script by the time you reach the end.

[outpaddling]

I just committed some simple changes to auto-adduser, auto-useradd, and auto-groupadd to support OpenBSD. These should provide good examples for other scripts. These are not fully tested, but auto-adduser did work on my OpenBSD VM.

Also, it looks like you can make work-in-progress auto-admin and desktop-installer ports available fir testing via https://github.com/jasperla/openbsd-wip.

[piranah]

I am at a loss, pathetic as it may be I have NEVER used git or committed like ever. I suppose now is as good a time as ever to get started. Gonna do a practice run on my own repos then get back to you. Reg, p

…

On Wed, Sep 27, 2023 at 4:53 PM Jason Bacon ***@***.***> wrote: I just committed some simple changes to auto-adduser, auto-useradd, and auto-groupadd to support OpenBSD. These should provide good examples for other scripts. These are *not* fully tested, but auto-adduser did work on my OpenBSD VM. Also, it looks like you can make work-in-progress auto-admin and desktop-installer ports available fir testing via https://github.com/jasperla/openbsd-wip. — Reply to this email directly, view it on GitHub <#30 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGN6PU6EBKNU6S45RRZNFDX4Q4W7ANCNFSM6AAAAAA5EM3UFA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[outpaddling]

No time like the present. For now, you can just clone the repo, edit the scripts, and send "git diff" output to this thread. I'll review and commit. Be sure to keep your copy updated by running "git pull" before every edit. When you get better with git[hub], you can learn about pull requests.

[Izder456]

Submitted a PR to get the ball rolling on this.

#37

[outpaddling]

Terrific, thanks for pitching in! Couple of things:

1. Can you please sign your work by adding your name to a block comment at the beginning of each script? Then people won't have to brows the git logs to figure out who the original author is.
2. Have you considered adding desktop-installer to https://github.com/jasperla/openbsd-wip/tree/master/sysutils? I'd suggest using your fork as the dist for the WIP port. Maybe also fork auto-admin and switch the WIP port for that to your fork. Then you and other OpenBSD users can easily test your latest changes.

[Izder456]

Thanks for the response:

1. Yes, i certainly can. that's totally reasonable.

2. I maintain a few ports myself, I plan to just port it when complete and submit it to the ports@ mailing list.

I have yet to get auto-admin up and working with openbsd, following the tips you posted here.

again, thanks for the great software!

[outpaddling]

2. I maintain a few ports myself, I plan to just port it when complete and submit it to the ports@ mailing list.

Well, I wouldn't regard it as fully tested unless it was installed via ports, since it relies on files being installed in the proper hierarchy.

I have yet to get auto-admin up and working with openbsd, following the tips you posted here.

openbsd-wip would solve this for you as well, installing auto-admin as a dependency.

Cheers...

[Izder456]

The auto-admin scripts that require platform-specific code use case statements controlled by auto-ostype, a wrapper around uname mainly to distinguish Linux distros from each other (uname just reports "linux", which is useless in determining sysadmin commands, which are specific to the distro, not the kernel).

case $(auto-ostype) in
FreeBSD)
     # FreeBSD code
     ;;

RHEL)
     # Redhat Enerprise code
     ;;

esac

Where the necessary commands are exactly the same as a supported platform, it would be a simple matter of adding "or OpenBSD", e.g.

FreeBSD|OpenBSD)

In other cases, you would need to add a new OpenBSD case and write the appropriate code. The command below lists the auto-admin scripts run directly by the NetBSD version of desktop-installer. You can go through these one-by-one (recursively since they may run other auto-admin scripts) and add OpenBSD cases.

# grep --only-matching 'auto-[a-z\-]*' NetBSD/desktop-installer | sort | uniq
auto-admin
auto-append-line
auto-automount-setup          # Low priority, can be added later
auto-enable-service
auto-install-base-components  # Low priority, can be added later
auto-package-installed
auto-pkgsrc-wip-checkout    # Not really necessary for OpenBSD
auto-replace-file
auto-update-pkgsrc              # Not necessary for OpenBSD
auto-update-system

Only a fraction of auto-admin scripts are required by desktop-installer, directly or indirectly, so this task is not as daunting as one might assume at first. Just identify which scripts are required and pick them off one-by-one.

I would approach it top-down: Start writing the desktop-installer script, using the NetBSD version as a model, and when you reach a point where an auto-admin script is needed, add the OpenBSD case to it and test it by running your desktop-installer. This way, you'll make steady progress and have a well-tested script by the time you reach the end.

outpaddling/auto-admin#10

Started and opened a PR for auto-admin to support this. Will be working on adding to openbsd-wip, for now, I'll need to work on modifying the desktop-installer's use of auto-admin on OpenBSD

EDIT:

submitted a PR for this to enable auto-admin support:

#40

[Izder456]

Submitted a couple PRs to finish this up.

I would like testers please.

#42
outpaddling/auto-admin#11

[Izder456]

added a PR to merge a port into openbsd-wip

jasperla/openbsd-wip#177

feel free to test when you can.

thanks for all the help @outpaddling!

[outpaddling]

I just ran a quick test installing Lumina desktop under VirtualBox, and it went pretty smoothly. Some notes:

1. The Lumina port is outdated
2. Shutdown from the Lumina exit menu doesn't work
3. No terminal emulator was installed by desktop-installer

[Izder456]

would you prefer another desktop in place of lumina if its that buggy? we might wanna place the user in the _shutdown group and see if that fixes the shutdown/reboot issue as that allows for rootless use of the shutdown cli utility

lxde isn't an option on openbsd as it hasn't been ported.

about the terminal: openbsd comes with xterm. although some of the "-extra" packages include each desktop's respective terminal. for desktops that don't have a terminal emulator, should we use something like sakura, or lxterm, or- maybe just use xterm?

ill be going through this later tonight and identifying all the outstanding issues, such as the ones ya mentioned

im thinking of just plopping lxterm on the lxqt and lumina (or whatever we replace it with) cases. I also plan to add the user to the _shutdown group across the board using auto-tools.

any objections?

[outpaddling]

would you prefer another desktop in place of lumina if its that buggy? we might wanna place the user in the _shutdown group and see if that fixes the shutdown/reboot issue as that allows for rootless use of the shutdown cli utility

I use Lumina 1.6.2 on FreeBSD. Don't have a preference for OpenBSD testing, just making issues known.

about the terminal: openbsd comes with xterm. although some of the "-extra" packages include each desktop's respective terminal. for desktops that don't have a terminal emulator, should we use something like sakura, or lxterm, or- maybe just use xterm?

ill be going through this later tonight and identifying all the outstanding issues, such as the ones ya mentioned

im thinking of just plopping lxterm on the lxqt and lumina (or whatever we replace it with) cases. I also plan to add the user to the _shutdown group across the board using auto-tools.

any objections?

I always try to install a modern terminal that registers as a desktop app, recognizes themes, has copy-and-paste in the menus, etc. Qterminal is the canonical choice for lxqt. It was once a generic Qt app, but was commandeered by the LXQT project. I now use coreterminal, and have contributed to upstream (bug fixes, code to snap to font size like GTK apps, an annoying omission from most Qt-based terminals). Coreterminal is very simple and generic, but aware of Qt themes. If it's not in OpenBSD ports already, I'd say it's worth adding.

I'd install a GTK terminal for GTK desktops, though.

[Izder456]

I always try to install a modern terminal that registers as a desktop app, recognizes themes, has copy-and-paste in the menus, etc. Qterminal is the canonical choice for lxqt. It was once a generic Qt app, but was commandeered by the LXQT project. I now use coreterminal, and have contributed to upstream (bug fixes, code to snap to font size like GTK apps, an annoying omission from most Qt-based terminals). Coreterminal is very simple and generic, but aware of Qt themes.

If I keep Lumina, I should likely go with qterminal, but I'm leaning towards putting another window manager or two, like i3, sdorfehs/ratpoison, or openbox instead. I am thinking window managers cos:

1. they are generally more appealing to those who want to use OpenBSD,
2. there are far more available window managers than desktop environments in the OpenBSD ports tree.

If it's not in OpenBSD ports already, I'd say it's worth adding.

I'll look into it, although I personally won't have a use-case for it as I use urxvt for nearly everything on my personal machine. I plan to have a less heavily configured "normie" system using my work on desktop-installer, so I'll use whatever we ship with this. Not much personal interest in porting a terminal I likely won't use basically.

I'd install a GTK terminal for GTK desktops, though.

I suppose sakura is a decent option for GTK as it supports all of these things:

https://github.com/dabisu/sakura

Although seems like the GTK desktops I chose to be supported for now, (ie: MATE & XFCE), all have their own terminal.

--

For now, I'll just swap lumina for i3, just for the reasons I listed above.

I'll also send a PR here automating the enabling of the apm service on laptops.

was going to automate adding to the _shutdown group, but ck-launch-session and the various bigger desktop environments already support passwordless shutdown, so its not needed, for now

--

In the furute, I also want to prompt the user if they want to add themselves to the staff login class and groups, as that will help with performance for many machines. Do you have some sort of auto-admin tool for adding users to login classes? Looks like auto-add-to-group doesn't support OpenBSD yet. I'll need to do some work with that later then.

[outpaddling]

If I keep Lumina, I should likely go with qterminal, but I'm leaning towards putting another window manager or two, like i3, sdorfehs/ratpoison, or openbox instead. I am thinking window managers cos:

1. they are generally more appealing to those who want to use OpenBSD,

2. there are far more available window managers than desktop environments in the OpenBSD ports tree.

was going to automate adding to the _shutdown group, but ck-launch-session and the various bigger desktop environments already support passwordless shutdown, so its not needed, for now

Forgot to mention, I assumed adding to wheel would allow shutdown. It does on FreeBSD and NetBSD. Some DEs rely on other things like polkit.

In the furute, I also want to prompt the user if they want to add themselves to the staff login class and groups, as that will help with performance for many machines. Do you have some sort of auto-admin tool for adding users to login classes? Looks like auto-add-to-group doesn't support OpenBSD yet. I'll need to do some work with that later then.

Adding users to groups should generally be done from auto-adduser or the auto-admin menu. I think these are mostly functional on OpenBSD already.

[Izder456]

Have a look at FreeBSD/desktop-installer. It has an option for users to install any DE or WM that's not in the list by providing basic info about it.

cool- I sent a PR removing lumina for now. if someone wants lumina, they can add it themselves.

Forgot to mention, I assumed adding to wheel would allow shutdown. It does on FreeBSD and NetBSD. Some DEs rely on other things like polkit.

this isn't the case on openbsd- although that _shutdown thing only really concerns base utilities. I don't think it concerns much in the way of ports.

Adding users to groups should generally be done from auto-adduser or the auto-admin menu. I think these are mostly functional on OpenBSD already.

roger- ill look into that script when I get around to this.

[outpaddling]

I don't think there is anything necessarily wrong with the Lumina port. It's just not up-to-date.
FYI, I reran and installed LXQT. Shutdown doesn't work there either, so there is apparently still some generic config to do.

[Izder456]

FYI, I reran and installed LXQT. Shutdown doesn't work there either, so there is apparently still some generic config to do.

Upon some reading into the pkg-readme, looks like all it needs is the messagebus package script enabled and running, we do this in the auto-enable-service step.

https://openports.pl/path/x11/lxqt/powermanagement

Likely, ck-launch-session may be causing issues like you warned me about. I'll look into this later tonight. I am currently sorta busy, but had some brief time to look into this.

Also, question: Both the xenodmshutdown script and the openbsd-background.jpg are not installed by either the desktop-installer script or the port. Would we prefer to do this with auto-replace-file? or the port itself? I'm leaning that the port should.

I forgot to add the RUN_DEPENDS for this bit:

# Should have been installed as a dep, but just in case
pkg_add dbus git gmake xz feh tk-8.6.13 consolekit2

I'll have to go through and fix up the port some more as well.

[outpaddling]

Also, question: Both the xenodmshutdown script and the openbsd-background.jpg are not installed by either the desktop-installer script or the port. Would we prefer to do this with auto-replace-file? or the port itself? I'm leaning that the port should.

The analogous files in the FreeBSD port and pkgsrc package are installed under $PREFIX/share/desktop-installer. They are then copied into place IFF the user chooses to enable xdm.

The pkgsrc PLIST:

@comment $NetBSD$
man/man1/desktop-installer.1
sbin/battery-shutdown.sh
sbin/desktop-installer
share/desktop-installer/CDE/cde.desktop
share/desktop-installer/CDE/xinitrc
share/desktop-installer/CINNAMON/xinitrc
share/desktop-installer/FLUXBOX/xinitrc
share/desktop-installer/GNOME/xinitrc
share/desktop-installer/ICEWM/xinitrc
share/desktop-installer/KDE5/xinitrc
share/desktop-installer/KODI/xinitrc
share/desktop-installer/LUMINA/gtkrc
share/desktop-installer/LUMINA/xinitrc
share/desktop-installer/LXDE/xinitrc
share/desktop-installer/LXQT/xinitrc
share/desktop-installer/MATE/xinitrc
share/desktop-installer/OTHER/xinitrc
share/desktop-installer/SDDM/sddm.conf
share/desktop-installer/WMAKER/xinitrc
share/desktop-installer/XDM/GiveConsole
share/desktop-installer/XDM/Xsetup_0
share/desktop-installer/XDM/netbsd-background.jpg
share/desktop-installer/XDM/xdmshutdown
share/desktop-installer/XFCE4/xinitrc
share/desktop-installer/Xdefaults-xterm
share/desktop-installer/battery-shutdown.cron

Generally speaking, the goal has been for the configuration done by desktop-installer to continue to function after desktop-installer is deinstalled. I have not rigorously confirmed this, however. If these files are removed by pkg_delete, the installation would be broken.

I forgot to add the RUN_DEPENDS for this bit:

# Should have been installed as a dep, but just in case
pkg_add dbus git gmake xz feh tk-8.6.13 consolekit2

That comment in the NetBSD script is outdated. I think it only referred to the "digest" and "fetch" pkgsrc packages, which are build depends for pkgsrc packages installed from source. Preinstalling them saves time if they get deinstalled after desktop-installer is installed. I accidentally added more packages to that pkgin command without regard for the comment.

# Should have been installed as a dep, but just in case
pkgin -y install digest fetch git cvs gmake xz feh tk consolekit

Looks like none of those OpenBSD ports need to be deps.

[outpaddling]

Just also noticed that my LXQT desktop icons are blank:

[Izder456]

Just also noticed that my LXQT desktop icons are blank:

I believe this is because lxqt does not set any icon theme by default, although it installs the oxygen icons. simply going to the system preferences, and setting oxygen icons, it works fine.

This is down to the lxqt port maintainer, cos I can replicate this on my testing laptop even with manually setting up and installing lxqt.

I'm nearing the point to message ports@ with this, although despite me reaching out to jasperla's email on their webpage, I lack write permissions still.

Could you merge this PR?

jasperla/openbsd-wip#178

[Izder456]

https://marc.info/?l=openbsd-ports&m=173127221019492&w=2

Started a thread in ports@

[outpaddling]

Just also noticed that my LXQT desktop icons are blank:

I believe this is because lxqt does not set any icon theme by default, although it installs the oxygen icons. simply going to the system preferences, and setting oxygen icons, it works fine.

Odd. I would call this a bug in the LXQT port.

[outpaddling]

https://marc.info/?l=openbsd-ports&m=173127221019492&w=2

Started a thread in ports@

Cool. If there are any security concerns in the OpenBSD community about auto-admin or desktop-installer, I would love to hear about them.

[Izder456]

Cool. If there are any security concerns in the OpenBSD community about auto-admin or desktop-installer, I would love to hear about them.

personally my main critique isn't about the software itself, but rather the implications.

see the security page on openbsd.org:

To ensure that novice users of OpenBSD do not need to become security experts overnight (a viewpoint which other vendors seem to have), we ship the operating system in a Secure by Default mode. All non-essential services are disabled. As the user/administrator becomes more familiar with the system, he will discover that he has to enable daemons and other parts of the system. During the process of learning how to enable a new service, the novice is more likely to learn of security considerations.

This is in stark contrast to the increasing number of systems that ship with NFS, mountd, web servers, and various other services enabled by default, creating instantaneous security problems for their users within minutes after their first install.

something like this piece of software has to enable services not necessarily audited by the same rigor as the base system. users may not understand the implications of enabling something such as dbus or avahi, and thus may make rookie mistakes in their personal opsec.

nonetheless- I could just as easily append a pkg-readme or install message for this port if you'd like to warn users of the potential security implications on their system? just an idea.

however- these implications are more or less true with all ports, so I still believe its good bit of software worth merging into the tree, so long as the user is informed of the implications I feel.

[outpaddling]

Cool. If there are any security concerns in the OpenBSD community about auto-admin or desktop-installer, I would love to hear about them.

personally my main critique isn't about the software itself, but rather the implications.

see the security page on openbsd.org:

To ensure that novice users of OpenBSD do not need to become security experts overnight (a viewpoint which other vendors seem to have), we ship the operating system in a Secure by Default mode. All non-essential services are disabled. As the user/administrator becomes more familiar with the system, he will discover that he has to enable daemons and other parts of the system. During the process of learning how to enable a new service, the novice is more likely to learn of security considerations.
This is in stark contrast to the increasing number of systems that ship with NFS, mountd, web servers, and various other services enabled by default, creating instantaneous security problems for their users within minutes after their first install.

something like this piece of software has to enable services not necessarily audited by the same rigor as the base system. users may not understand the implications of enabling something such as dbus or avahi, and thus may make rookie mistakes in their personal opsec.

nonetheless- I could just as easily append a pkg-readme or install message for this port if you'd like to warn users of the potential security implications on their system? just an idea.

however- these implications are more or less true with all ports, so I still believe its good bit of software worth merging into the tree, so long as the user is informed of the implications I feel.

To address that, I would add an output message followed by a pause whenever desktop-installer enables a daemon. Maybe even require a specific acknowledgment rather than just "Press return" from the user if you want to be strict.

Note: The dbus daemon has been enabled.  This has the following security implications:
yada, yada...
Type "got it" to continue.

[outpaddling]

Back to the login class question, which I overlooked before:

No, auto-admin doesn't currently support changing the login class. We could create a new auto-change-login-class script for this. On FreeBSD, this is simple:

pw usermod -n name/uid -L class 

[outpaddling]

I just added auto-change-login-class to the WIP ports and pkgsrc package. Please give it a try...

[Izder456]

I just added auto-change-login-class to the WIP ports and pkgsrc package. Please give it a try...

I'll give this a shot. Thanks.

To address that, I would add an output message followed by a pause whenever desktop-installer enables a daemon. Maybe even require a specific acknowledgment rather than just "Press return" from the user if you want to be strict.

I decided this to be an unneeded feature for this software. I will add a pkg-readnme in the port with a warning of how it enables daemons. This is the more or less standard way to do these sorta "OpenBSD-specific notes" for lack of a better term.