Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

New OS request - NOT an ISSUE #30

Open
piranah opened this issue Sep 23, 2023 · 20 comments
Open

New OS request - NOT an ISSUE #30

piranah opened this issue Sep 23, 2023 · 20 comments

Comments

@piranah
Copy link

piranah commented Sep 23, 2023 •
edited
Loading

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
Copy link
Owner

outpaddling commented Sep 23, 2023 •
edited
Loading

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
Copy link
Author

piranah commented Sep 26, 2023 via email

@outpaddling
Copy link
Owner

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
Copy link
Owner

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
Copy link
Author

piranah commented Sep 28, 2023 via email

@outpaddling
Copy link
Owner

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
Copy link
Contributor

Submitted a PR to get the ball rolling on this.

#37

@outpaddling
Copy link
Owner

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
Copy link
Contributor

Izder456 commented Jun 26, 2024 •
edited
Loading

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
Copy link
Owner 

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
Copy link
Contributor

Izder456 commented Oct 21, 2024 •
edited
Loading

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

This was referenced Oct 25, 2024
Merged
Merged
Merged
@Izder456
Copy link
Contributor

Submitted a couple PRs to finish this up.

I would like testers please.

#42
outpaddling/auto-admin#11

@Izder456 Izder456 mentioned this issue Oct 29, 2024
Merged
@Izder456
Copy link
Contributor

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
Copy link
Owner

outpaddling commented Oct 29, 2024 •
edited
Loading

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
Copy link
Contributor

Izder456 commented Oct 29, 2024 •
edited
Loading

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
Copy link
Owner

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
Copy link
Contributor

Izder456 commented Oct 29, 2024 •
edited
Loading

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
Copy link
Owner

outpaddling commented Oct 30, 2024 •
edited
Loading

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
Copy link
Contributor

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
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@piranah @outpaddling @Izder456