01:33:24 hello 01:34:57 https://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 01:44:48 bombuzal: Glad to hear it! 01:45:21 \o/ 01:46:53 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 01:52:56 honestly nor much has changed since 4.x except you can put down your compiler now :) 01:54:03 lol 01:54:51 I imagine there are a million* more ways to manage jails now, and add bhyve on top of that 06:54:53 so i have a very basic question 06:55:25 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 06:55:49 put the correct line(s) into rc.conf 06:56:34 defaultrouter ifconfig_em0 etc 06:57:04 look at `man rc.conf` or in the file /etc/defaults/rc.conf 07:24:46 as a lifetime mac user, this is a weird way to set up the network 07:25:02 so if i randomly wanted to change my IP without rebooting, how would i do that? 07:38:50 by using ifconfig 16:05:25 An X in the password field via vipw locks the account? 16:06:14 by causing a syntax issue or something? 16:06:24 I'm asking. 16:06:27 idk 16:08:04 vipw 16:08:09 whoops 16:09:00 I guess it's * 16:32:11 CrtxReavr: anything that doesnt hash 16:32:45 GoSox: ifconfig em0 10.11.32.19/24; route delete default; route add default 10.11.32.1 16:44:41 CrtxReavr: use "*LOCKED*" to lock the account, see passwd(5). 'x' or '*' will not lock the account 16:44:48 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. 16:47:24 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. 16:56:00 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. 16:56:09 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 *. 16:56:16 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. 16:56:24 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. 16:56:27 The "pw lock someuser" and "unlock" commands are programmed to work with the "*LOCKED*" string specifically. 16:57:01 The https://docs.freebsd.org/en/books/handbook/security/ has a section on preventing logins. 16:59:04 What did the bash global config file change to? 17:00:50 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? 17:27:11 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. 17:28:23 Hmm... On 14.3-RELEASE my version of the bash man page does list that file. What version are you running? 17:32:11 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. 17:33:14 https://man.freebsd.org/cgi/man.cgi?query=bash&apropos=0&sektion=0&manpath=FreeBSD+15.0-RELEASE+and+Ports.quarterly&format=html 17:33:40 Running strings on the bash executable confirm the path though: strings /usr/local/bin/bash | grep profile 17:35:45 I guess it is time to file a bug against the online man pages because that is mismatched with the actual installation. :-( 19:14:48 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 19:15:10 *stopping the messages going into /var/log/messages 19:19:37 dvl: the easiest way would be to configure openvpn to use a different syslog facility, if it supports that? (like local1) 19:19:57 ivy: I see no ability to specify facility for openvpn. :/ 19:20:21 ivy: I'd go with local5 or something like that; time proven. 19:26:54 I have it logging to the separate file. It's the duplicate which is annoying. 19:33:05 openvpn uses the daemon facility, which means the logs are now going to three files. 19:39:57 dvl: you can do something like 19:39:59 !-knot,bird 19:40:00 daemon.info /var/log/daemon.log 19:41:35 (but i find this annoying to maintain and wish more software let you change the facility) 19:52:51 dvl: In the past, I'd always just used "log-append /var/log/openvpn.log" in the config. Is that no longer relevant? 19:55:01 ek: That works, but log rotation cannot be done easily. openvpn keep logging to the rotated file. I tried that overnight. 20:07:25 dvl: Using newsyslog? 20:07:44 ek: yes, rotated with newsyslog 20:09:50 dvl: What line do you have for the rotation in newsyslog? Specific SIG sent? 20:10:52 No SIG at all. 20:11:33 ek: Earlier today, I tried a KILL -30 . no help 20:14:09 ek: I'm trying to understand your suggested change. 20:14:27 dvl: Have you tried -1 (HUP, SIGHUP)? I'm pretty sure that's what I used? 20:14:55 Apologies as it's been a while since I've run OVPN. 20:16:18 Logging in work to /var/log/openvpn.log, correct? Just not rotating as expected? 20:16:27 s/in work/is working/ 20:16:43 When using log-append='/var/log/openvpn.log' 20:17:13 Reading signals for openvpn, it doesn't close log files - however, I will try -1 (after this task) 20:20:21 Always a brave move to modify the vpn configure, then restart it, when you're connected via that vpn. 20:21:20 Power just went out here. As I restarted openvpn.... 20:21:28 Haha. Gotta have some trust in there somewhere! 20:21:30 And it's badk on. 20:21:53 The logging is confirmed only to said file. I will wait overnight. 20:22:04 I do remember running into a similar issue. Trying to look through my old notes/configs to see if I can find a solution. 20:22:26 I did just find this: https://forums.openvpn.net/d/28205-openvpn-log-rotation-on-freebsd 20:22:52 This is why I have the UPS to get through short outages, which take minutes to recover from. 20:23:19 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? 20:26:57 ek: search for "SIGNALS" - there's a section 20:27:52 ek: Or click on SIGNALS at the bottom of https://man.freebsd.org/cgi/man.cgi?query=openvpn 20:37:08 dvl: It seems like SIGUSR1 would be the obvious choice. But, without reloading, perhaps that doesn't work with the log file? 20:37:39 I see no mentions of log files on the man page with sigs 20:37:48 Doing a full HUP and having TUN/TAP defunct and restarted seems silly for something as simple as log rotation. 20:37:48 ek: I have doubts, but will try tomorrow. 20:37:56 exactly 20:38:24 Okay. Well, good luck, sir! I'm curious how it turns out. 20:38:47 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. 20:55:36 We shall see. 20:56:12 ek: I read that same forums page earlier today. 20:57:00 "No logs in the new file" - I think they have not noticed the logging is still going to the old file. 20:59:13 Yeah. That's a problem. 21:36:26 mitmproxy is broken, is there alternative ? 21:37:20 found, thanks ;) 21:46:33 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 22:16:25 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.