hello

ibb.co/JjfHQxY8 - decided to install FreeBSD 15 on a Thinkpad X1 Yoga (gen 6) - runs like a dream; Wayland+KDE Plasma 6 :). Xorg needs some extra help but I cba editing Xorg confs because they're hideous

bombuzal: Glad to hear it!

\o/

I used FreeBSD from 4.x to 7.x (and dabbled a bit upto 9.x) then kind of dropped off a bit - trying to get back into it and I guess the best way to do that is immerse myself in it XD

honestly nor much has changed since 4.x except you can put down your compiler now :)

lol

I imagine there are a million* more ways to manage jails now, and add bhyve on top of that

so i have a very basic question

how do you configure the network connections on freebsd? I have yet to ever do that, other than selecting dhcp at install time. Of all the GUIs i’ve tried, none have had any network settings built in

put the correct line(s) into rc.conf

defaultrouter ifconfig_em0 etc

look at `man rc.conf` or in the file /etc/defaults/rc.conf

as a lifetime mac user, this is a weird way to set up the network

so if i randomly wanted to change my IP without rebooting, how would i do that?

by using ifconfig

An X in the password field via vipw locks the account?

by causing a syntax issue or something?

I'm asking.

idk

vipw

whoops

I guess it's *

CrtxReavr: anything that doesnt hash

GoSox: ifconfig em0 10.11.32.19/24; route delete default; route add default 10.11.32.1

CrtxReavr: use "*LOCKED*" to lock the account, see passwd(5). 'x' or '*' will not lock the account

rtprio, fyi: route has a "change" action (man route says "change Change aspects of a route (such as its gateway)." Instead of deleting and adding one can "route change default 10.11.32.1" and switch gateway routers in one command.

The main reason I suggest that is that I have in the past done things where I was adding and removing routes scripted for automated route changes and gotten them out of sync such that I found I had a "route leak" such that I had many routes stacked up because they were not getting deleted but they were getting added. Switching to change avoided that pitfall entirely.

CrtxReavr, Traditionally we use a "*" to in the password field to disable passwords because the characters used to encode passwords does not produce a * and therefore can then never match. The * is obvious to a human and can be added and deleted in vi easily by human eye so the password could be enabled again easily later. It does not have to be a * but that's the idiom since the beginning.

Automated tools (elsewhere anyway) use a single "x" which again is not an empty passwd field but cannot be matched and is easily discernable and different from the human *.

Note that disabling the password does NOT disable the account. Other login authentication methods are still active such as ssh keys. One can still ssh into the system.

That's where ivy's suggestion to use "*LOCKED*" comes in. Someone put in a hack to look for that string in the password field and if it is there then that blocks ssh logins.

The "pw lock someuser" and "unlock" commands are programmed to work with the "*LOCKED*" string specifically.

The docs.freebsd.org/en/books/handbook/security has a section on preventing logins.

What did the bash global config file change to?

CrtxReavr, I don't quite follow. Are you asking about the "INVOCATION" section of the "man bash" listing the list of files bash reads at startup for a login shell? Or for a non-login shell?

rwp, I figured it out. . . for reasons unknown, it's /usr/local/etc/profile, but the installed bash(1) page makes no mention on this install.

Hmm... On 14.3-RELEASE my version of the bash man page does list that file. What version are you running?

Hmm... My local man page installed with "pkg install bash" for bash-5.3.9 has it (verify with "man bash | col -b | grep /usr/local/etc/profile" to see it) but the online man pages do not say that but say "/etc/profile" for it instead. Looks like a problem with the online man pages.

Running strings on the bash executable confirm the path though: strings /usr/local/bin/bash | grep profile

I guess it is time to file a bug against the online man pages because that is mismatched with the actual installation. :-(

At present, I have openvpn logging via syslog. The log entries are going to /var/log/message - I want them in /var/log/openvpn.log - my first step is stopping from from

*stopping the messages going into /var/log/messages

dvl: the easiest way would be to configure openvpn to use a different syslog facility, if it supports that? (like local1)

ivy: I see no ability to specify facility for openvpn. :/

ivy: I'd go with local5 or something like that; time proven.

I have it logging to the separate file. It's the duplicate which is annoying.

openvpn uses the daemon facility, which means the logs are now going to three files.

dvl: you can do something like

!-knot,bird

daemon.info /var/log/daemon.log

(but i find this annoying to maintain and wish more software let you change the facility)

dvl: In the past, I'd always just used "log-append /var/log/openvpn.log" in the config. Is that no longer relevant?

ek: That works, but log rotation cannot be done easily. openvpn keep logging to the rotated file. I tried that overnight.

dvl: Using newsyslog?

ek: yes, rotated with newsyslog

dvl: What line do you have for the rotation in newsyslog? Specific SIG sent?

No SIG at all.

ek: Earlier today, I tried a KILL -30 . no help

ek: I'm trying to understand your suggested change.

dvl: Have you tried -1 (HUP, SIGHUP)? I'm pretty sure that's what I used?

Apologies as it's been a while since I've run OVPN.

Logging in work to /var/log/openvpn.log, correct? Just not rotating as expected?

s/in work/is working/

When using log-append='/var/log/openvpn.log'

Reading signals for openvpn, it doesn't close log files - however, I will try -1 (after this task)

Always a brave move to modify the vpn configure, then restart it, when you're connected via that vpn.

Power just went out here. As I restarted openvpn....

Haha. Gotta have some trust in there somewhere!

And it's badk on.

The logging is confirmed only to said file. I will wait overnight.

I do remember running into a similar issue. Trying to look through my old notes/configs to see if I can find a solution.

I did just find this: forums.openvpn.net/d/28205-openvpn-log-rotation-on-freebsd

This is why I have the UPS to get through short outages, which take minutes to recover from.

Kinda relates to the same thing? Although, I'm not sure why referencing "--log" in the manpage really provides a solution. It does mention HUP and SIGUSR1, though. Says they're ignored?

ek: search for "SIGNALS" - there's a section

ek: Or click on SIGNALS at the bottom of man.freebsd.org/cgi/man.cgi?query=openvpn

dvl: It seems like SIGUSR1 would be the obvious choice. But, without reloading, perhaps that doesn't work with the log file?

I see no mentions of log files on the man page with sigs

Doing a full HUP and having TUN/TAP defunct and restarted seems silly for something as simple as log rotation.

ek: I have doubts, but will try tomorrow.

exactly

Okay. Well, good luck, sir! I'm curious how it turns out.

I'll still try to dig up my old notes/configs. I'm quite sure I dealt with exactly this years ago and did find a solution.

We shall see.

ek: I read that same forums page earlier today.

"No logs in the new file" - I think they have not noticed the logging is still going to the old file.

Yeah. That's a problem.

mitmproxy is broken, is there alternative ?

found, thanks ;)

I haven't tried yet, but my understanding of newsyslog with nginx is that SIGUSR1 is specifically for telling nginx to reopen the log file upon log rotation... i look forward to experimenting

scoobybejesus, Yes. I use /usr/local/etc/newsyslog.conf.d/nginx.conf "/var/log/nginx/*.log 644 5 1000 * BCG /var/run/nginx.pid" which will cause a SIGHUP to be sent to the nginx pid in that file.