why does portmaster need a command to do it; can't you just "cd /usr/ports/www/nginx && make rmconfig "

oops my bad

portmaster has --force-config that forces a configuration menu to be displayed on the screen. but for some reason, developers decided that portmaster doesn't need the option that resets configuration choices to their default values.

Oleg: I tried with chatgpt3.5 before for help with options, but it will vary based on linux vs bsd and date and so forth. I had slightly better luck just pasting the manpage and asking for a summary

e.g. which option does xyz or given option x can i have option y. those kinds of questions

the man page says that --force-config runs 'make config' for all ports. so it's equivalent to "make config-recursive". but what is portmaster's equivalent to "make config", instead of "make config-recursive"?

Oleg, just delete the <jailname>-options/<port>/options file

then when you rerun poudriere options it will prompt with default options again

ahh... sorry, I just realised you were asking about portmaster, I don't know where I got poudriere from

I already know that poudriere has things such "poudriere options -c", "poudriere options -c -n", etc.

I mean, such as

but yeah, the same idea still applies as rtprio said, just remove the config files manually if you want to force defaults

even with poudriere, -c won't show the default options if you have made any changes, it just forces the config menu if you want to change what is already there

edenist: but it has -r for resetting port configuration options to their default values

true, which as far as I understand just deletes the file I mentioned above

if portmaster doesn't have that, then the devs didn't think it was something worth their time I guess. ¯\_(ツ)_/¯

My questions are specifically about portmaster. --force-config has a recursive effect. what if I want to configure options for just one port? poudriere would allow me to do it with "poudriere options -n", but what about portmaster?

it looks like portmaster is an incomplete program, unlike poudriere.

who defines "complete" though?

if it is not complete for you, then you are free to modify it to make it so for your purpose

Portmaster is a tool designed to make port builds (manually) easier. Not a tool to make completely automated port builds. Like any manual port intervention, it is the responsibility of the person building to maintain their build config options (even with Poudriere.) If you want a default config put back into place, remove the ports' config via "make rmconfig" or delete the

/var/db/ports/category_port/options file. Either will do.

If you want all ports to have default options again, just delete all /var/db/ports/*/options files.

I use both portmaster and poudriere and I find myself doing this quite often. I then just run the "make config" (or "poudriere -c -n") for each top-level port I need non-default options for. Set the wanted options, and run the bulk (re-)build or upgrade.

To be honest, I find poudriere to be quite difficult to predict. I like the fact it can fetch packages instead of building everything from source (when default options are selected,) but each build attempt seems to be hit or miss. Sometimes, even with default options, poudriere will still build everything from source (devel/rust drives me nuts.)

While, I know every time, portmaster will build exactly what I expect (because it's always from source.)

I wouldn't use poudriere at all if it were for some ports (mostly flavors) that simply won't build from ports alone. It *MUST* be built using poudriere for some reason. I haven't looked too deep into it, but it's kind of a bummer.

really? i didn't know that existed

build rust *everrrry* day

i dont know why rust port cant have rust-lts as a port and ports needing generic rust build against that

it takes over an hour just for rust on even a modern machine with loads of ram and uses a significant amount of energy each time

rust has been a disaster for the cpu

I'm fine with rust as a language, but yeah from a bootstrapping perspective it is an absolute pain pain pain, and a real flaw currently IMO. If people really want to start pushing rust over things like C, then they need to work on getting the bootstrapping process more streamlined and supported across more systems

so myuser has a dir and some files at /usr/local/share/myuser/foo/ but when i try to rm the files in foo/ it says permission denied. but ls -la shows foo/ and its files as owned by myuser:myuser and the file perms are 644

so why not permission?

oh 1 of the higher dirs has dr-x------- perms maybe that's it?

alepzi, I did some playing and learning about pw and this is what I learned.

If the password field has a '*' in it then the account is password disabled but other authentications such as ssh keys are still allowed. That's the traditional method. That's the result of "pw ... -w no".

If the password field has "*LOCKED*" at the start of it then the account cannot be authenticated by any means. That's the result of "pw locked username".

ahhh

I think you are right that the documentation is out of date with respect to ssh logins and instead of saying login disabled it should say password disabled in the man page and in the handbook.

so that's all the more reason for -w no man page to say password auth is disabled and not "login"

ya

pw locked man page entry should definitely say disables login

I think this probably occurred when PAM was introduced. Before PAM, pluggable authentication modules, if the password was disabled it was effectively an account disable.

But now with PAM it means that there are other possible authentication methods. One time passwords. Other things. So at that point I think the documentation needed update but never got update.

really clear, nice job

Meanwhile... I don't really know. That's just my guess looking at the history of how we got here.

The thing I learned today was that on FreeBSD "*LOCKED*" as from "pw lock rwp" does prevent ssh logins. And all logins that I could test. That's not true on other systems such as the Debian derived systems. And it wasn't that way on old Unix systems such as HP-UX either. So that seems to be a FreeBSD introduced behavior. But honestly I did not look at OpenBSD or NetBSD so I don't know if it is just BSD derived behavior.

so -w no '*' disables pass auth, and locked username '*LOCKED*' disables all auth methods; login. <-- yea?

Yes. Traditionally we would edit the /etc/passwd file and "star out" the password field to disable the account. Since no hashed character is a '*' the hashed password can never match.

And then it was easy to re-enable the account by deleting the '*' and the old hash was re-instated and the account enabled.

old hash re-instated from where?

The "pw usermod -w no" wipes out the existing password entirely and replaces it with a '*'.

If one is editing the passwd file, today as in like using "vipw" to edit the file, then in the editor just insert a '*' at the start of the password hash. And then you can delete it later.

ahhh

nice

Editing a line like :$6$huG/QJ6XxfmfUiMx$7Tblahblahblah...: just change it to :*$6$huG/QJ6XxfmfUiMx$7Tblahblahblah...: adding a star at the front. No hash character is a '*' and so the field can never be matched with a password.

And then deleting the '*' restores the field. I don't see a command line helper tool that does this since as I said "pw usermod -n rwp -w no" will wipe out the field and replace it with a single star with ":*:" there.

Before we had all of these account database helpers we always just edited the file with vi and typed away and that was that. (shrug)

maybe some kinda pw togglelock username ?

Someone could code that up and add it to the command.

or i guess it would need to be an 'undoable' mode for both -w no and locked

like a -U flag or something that controlled how the pass hash field was handled

Since FreeBSD has this password database it's more of a pain to just edit the file. The helpers are nicer now because they syntax check for mistakes and they automatically run the pwd_mkdb to update the .db file automatically.

ya, just gotta fill in a couple more feature gaps seems like

asked in #openbsd what their behavior is just for fun i'll paste if they reply

On Debian family systems "passwd -l rwp" is documented the same way as locking the account but it stars out the password field using a '!' inserted at the front of the password hash.

And "passwd -u rwp" will unlock the account by removing the '!'.

And in this use '!' is the same as '*' in that it cannot ever be matched. But '!' is different from '*' in that the tool uses ! instead of * so that it can tell what the tool added versus what a human edited.

nice

i like non-destructive editing, where the lock can be taken off and the old pass hash is valid again

Again in Debian family systems "locking" the password field does not prevent ssh logins. So additionally one must "usermod -e 1 rwp" to set the expiration to seconds and 1 is definitely expired now. And use "usermod -e '' rwp" to remove that expiration field. Expired accounts cannot be logged into by ssh using other authentication methods.

#openbsd said man 5 passwd; /13 asterisks

lol

And just a by-the-by but if someone has had an account on a system and you are asked to disable their account then don't forget to remove any personal crontab that user may have installed and running or cron will continue to run it for them.

13 asterisks huh? I guess the additional 12 are for safety. :-))

HAHHA

Now that I think I understand this for FreeBSD I need to update my docs to include it as well as GNU/Linux systems: proulx.com/~bob/doc/howto-disable-a…ccounts/howto-disable-accounts.html

Title: HOWTO Disable Accounts

ya!

and maybe open a PR with the background and man page fix? (-w no doesn't disable login, it disables pass auth)

might be good advertising for your blog

It doesn't really matter to me if people see my doc articles or not. It's mostly doc for myself later when I need to do something I know I last did a couple of years ago and have slept since then and forgotten so need to read what I need to know to do it again.

I need to test for myself what FreeBSD does with the expire field. I think that should work here too. The Handbook docs.freebsd.org/en/books/handbook/security lists two methods 1) pw lock rwp and 2) chsh -s /usr/sbin/nologin rwp but I think "pw usermod -n rwp -e 1" would, should, maybe, also disable the account because then it would be expired.

Title: Chapter 16. Security | FreeBSD Documentation Portal

alepzi, I see your question above about rm -rf not removing a directory tree if the directories are not writable by the user. Yes. That needs "chmod -R u+w" run on the directory first and rm -rf does not do this intentionally because it is (sometimes) dangerous enough as it is.

Those directories are sometimes created when a copy of a data cdrom/dvd is made and of course on that media it's all read-only there.

rwp: did you figure out why freebsd introduced that behavior?

oh i see the usermod expire thing is needed to prevent ssh logins

I wonder when is the pkg quarter (FreeBSD 14) update date? Any idea?

johnjaye, Everything is behaving logically. The only unique feature is the "*LOCKED*" which is a feature I have not seen on other operating systems before.

oh ok

And yes there is authentication and then authorization. One might use any of several methods of authentication such as passwords, ssh keys, 2-factor devices, one time passwords, other things.

studying the differences between linux and freebsd has been an interest of mine lately

And then even if authenticated the question is if the account is authorized. So that's a separately controllable thing.

GNU/Linux systems don't have the "*LOCKED*" feature. Disabling passwords does not disable the account. So there one must use the expiration feature "usermod -e 1". Expired accounts are unavailable even if one can authenticate using ssh keys.

I just tested that on FreeBSD and it works as expected. So perhaps in the Handbook that might be listed as a 3rd method of disabling the account behind locked, and perhaps even above changing the shell to /usr/bin/nologin as I think it is more direct.

Another component that some systems use for authorization is if the configured user shell is listed in /etc/shells or not. ftp is an example that has used that requirement. If not listed then access is denied.

ah i see

tercaL: the quarterly branches should get created at the start of a quarter (so the next one beginning of april) and then only get cherry-picked commits from the latest branch

thanks a lot nimaje!

if you got an app server executable in /usr/local/bin and you need to update it sometimes, is it better to keep it somewhere else and symlink to it from /usr/local/bin so that the app server user doesn't need permission to write into the dir?

Hi, any idea if it is possible to generate medadata backup for a geli device ?

alepzi: how about writing a port, potentially in a private ports tree or overlay and than update via poudriere+pkg?

ya next, but want simpler for now

meandrain: i think by geli backup

any success with Raspberry 5 so far anyone? still a new-kind of bootcode missing ?

Success-speedening for all of you.

has anyone here tried to have bhyve use netgraph type bridging interfaces to be able to get network working for a bhyve freebsd image?

i am "trying" to have bhyve use a netgraph hook i created instead of a tap inteface

hi! there are no official downloadable images for FreeBSD 14 with cloud-init set up, right?

seems like something meena might be able to answer (sorry for the ping if not)

koalillo: yesno…

koalillo: we have AMIs with cloud-init on AWS, but the FreeBSD release team doesn't build images with cloud-init… yet

I hope it becomes standard.

i am currently trying to build an AMI with a development snapshot of cloud-init to test some things.

no worries, I thought that was the case- I just wanted to confirm I wasn't missing anything obvious

Does anyone know what ovref and ivref are in reference to audio?

ok so i can use seq 3 for speakers and the (numbers in here) are telling you the sequence of associated pins

so where i set nid2 nid3 nid 36 nid 37 theyre separate pins , so gpio 0:open 1 2 3 4: 5 6 7 and as=1 nid2 as=2 nid2 as=1 nid36 as=2 nid37 and seq 3 nid2 seq 3 nid36 seq 3 nid3 seq 3 nid37

did i do it right?

and nid44 is also associated with 1 and seq=15

so has to count them upwards if 1 doesnt work shelf them up to 1,2 2,3 3,4

is what im assuming because cad0/hdacc/hdac would have a specific pcm/interface

this is for a :"Dolphin" dual nic Interface_IC/Codec_IC Cirrus Logic 8xxx 4xxx chip.

meaning its like 8409 42l2

or something

crest: the router has landed :)!!!

voy4g3r2: which router?

the mikrotik ap running RouterOS level 6?

the hap ax3

it has routeros 7 on it

crest: i think you were the one responding on twitter about VPP and netgragh, right?

Title: MikroTik Routers and Wireless - Products: hAP ax³

voy4g3r2: that was you on twitter?

yes i commented on netgraph (and netmap)

how do you set the working directory in an rc.d init script? (i'm using `daemon`).. it looks like `daemon` has -c, but it just sets it to /.. i tried ${name}_chdir=/path, but it doesn't seem to have any effect

wcarson: from rc.conf(5), ⟨name⟩_chroot

chroot is different, that sets a chroot environment

chroot is probably going to be too limiting of an action though. libraries and such would need to be installed in the chroot for most programs. And I assume a "most program" situation because daemon is being used to run it.

i just want to change the working directory

Can you simply cd there before invoking daemon on your program?

i'm not sure where to put that in the rc script. i tried putting a nake 'cd /path' in there, but it doesn't do anything (i didn't expect it to)

i wonder if the app is doing something dumb like `cd /$HOME` and $HOME is not set

I looked at /etc/rc.subr and find that run_rc_command documents ${name}_chdir n Directory to cd to before running ${command}

lol, yes, that was exactly it. setting HOME fixed it

${name}_chdir was probably working the whole time. sigh.

Seeing all of the ping drops makes me wonder if we are having a netsplit?

What program are you trying to run that can be run as a daemon but is not set out of the box to run as a daemon?

It's also a hack and also a time honored technique to use cron and the @reboot time specification to start userland programs. I use this for starting a tmux session automatically on my main server. And in the tmux I start irssi my IRC client which connects me here. I am using it for this communication now.

Hi folks! I'm about to install an old version of Nextcloud from pkg install /var/cache/pkg/nextcloud-php80-25.0.2_1.pkg. However, it complains about missing dependencies. Is it possible for pkg to automatically install its dependencies?

I mean, instead of installing each dependency manually... *puh*

andreas303, I don't know but... It seems like pkg install should have already queued dependencies for installation if they were available. If it does not then that makes me think they are not available for install.

rwp: All of the dependencies of nextcloud are in /var/cache/pkg, but I don't understand why pkg doesn't install the dependencies automatically.

andreas303, Look at pkg-check the -d and -a options. -d says "Checks for and installs missing dependencies".

Also the example includes an example for it automatically installing dependencies.

Clearly I don't know from my own experience.

rwp: Oh, OK, thanks! Though, now I've already installed all dependencies manually. :) But now I have another problem. I've recently upgraded from FreeBSD 13 to FreeBSD 14. Now, when I do "service php-fpm restart", I get "ld-elf.so.1: Shared object "libcrypto.so.111" not found, required by "php-fpm"". Could that have something to do with the upgrade?

rwp: Several packages "disappeared" during the update: nextcloud, php, among others...

...and I don't know why. :-/

I have libcrypto.so.30 in /lib. Shouldn't that have been upgraded during the upgrade from FreeBSD 13 to FreeBSD 14?

andreas303: yes, it should have

rtprio: Hmm, strange. Do you have any suggestions about how to fix the half-finished upgrade?

rtprio: /etc/os-release says FreeBSD 14, so I assumed that the upgrade was finished and successful.

i think you should force-reinstall of the php packages

preferably all the packages

is it possible to add a loopback interface to a jail?

rtprio: is there a quick way to do that?

andreas303, As to packages disappearing, I believe that is simply an artifact of the way pre-compiled pkgs are served, and there are always quarterly and latest release builds running. The packages will re-appear in the repositories after the builds complete. I am fuzzy on details but that's what I have observed before.

andreas303, As to your base update, everything depends upon if you have finished the update of base yet or not.

andreas303: pkg upgrade -f

After doing the "freebsd-update install" to install it then you need to reboot and then run "freebsd-update install" again to finish the installation. And then after that you need to do "pkg-static upgrade -f pkg" possibly using pkg-static if pkg itself is broken (shared libraries in base) by the base upgrade.

And then I reboot again so that all of the ports daemons and everything is guaranteed to be restarted.

If there is a problem of some sort, usually I only hit problems when I have not followed all of the steps, then freebsd-update automatically makes ZFS snapshots and one can use those snapshots to recover if needed. Also Boot Environments are available too.

Upgrades are extremely reliable because FreeBSD base is one cohesive thing upgraded all together.

Most problems occur in ports which are linked against the previous base shared libraries. Doing a full pkg upgrade -f of everything gets everything upgraded to use the new base system.

And of course the source compiled systems using base as source and ports from source know they need to recompile everything there too.

the only area i've had a problem was: php packages

and the one time pkg upgrade removed the mysql that was installed

oh, easy enough... cloned_interfaces="lo1", service netif cloneup; ip4.addr = "lo1|127.0.2.1", "re0|192.168.2.100"; service jail restart myjail; jexec myjail vi /etc/hosts, change localhost to 127.0.2.1, bingo bango.

I am trying to set up an ssh tunnel using the -w option as a non-root user. Any ideas on how to accomplish this?

woah; never knew that was a thing

rtprio: looks pretty simple, but you must somehow allow users to allow tun interfaces

*create

Gud: i have a feeling it's not possible, but i don't know. one alternative would be to run it in a jail as root, with the tun device accessible in that jail (though i don't know if root in jail is strictly more secure than non-root outside of jail)

actually, it might be possible. the failure might have something to do with ssh security policies of some kind

so might be possible to change that

and i meant to say "as secure as" not "more secure than" above