you may be able to set the display mode on boot, but I only have older RPIs so I don't know how

I don't really know if it's framebuffer or not, I did an install, installed xorg and xcfe, wrote an ~/.xinitrc file, then ran startx

I see not enough current docs or wiki entries to know what to do

kids these days don't use x, they use wayland

mmlj4: chapter 8.2.3.3 in docs.freebsd.org/en/books/handbook/desktop

Title: Chapter 8. Desktop Environments | FreeBSD Documentation Portal

nothing there is relevant to the question

any way to make the scripted bsdinstaller not put zfs_enable="YES" in /etc/rc.conf? i already have it in /etc/rc.conf.d/zfs!!

I'm looking at this: elinux.org/RPi_Configuration # hdmi_safe=1 is set in /boot/msdos/config.txt, but that defaults to hdmi_mode=4 which that page says is hdmi_mode=4 720p 60Hz # maybe I can fiddle with it?

Title: RPi Configuration - eLinux.org

but this is an off-the-shelf HDMI monitor :-/

yeah... I can change it! woot!

I'll have to go on site and fiddle wit it on their huge TV, but this'll work :-)

when you guys make a set of config files that customize freebsd how you want, does that set of config files only contain what's different than the stock install, or does it even include default configs?

feels redundant to pull default config into my custom set, but at the same time keeping an incomplete config set also has downsides

I would set all the configuration explicitly that is wanted. That was way not have to rely on things changing underneath|"without notice"; may help in chasing bugs

s/was //

parv ok but default configuration that isn't explicitly wanted, leave it out of the custom config?

polyex, If you do not care, for example ZFS support, yes leave it out

depends what the config is

like, FreeBSD has /etc/defaults/<configfile>

and then you override it in /etc/<configfile>

or /etc/<thing>.d/<snippetfile>.conf

etc

so that you can auto-inherit defaults you didn't explicitly change

ya, and all of the overriding i do from the stock install, is in my custom config set. what i was wondering is if i should bring more than the 'diff' into my config set but i think parv is right, that i shouldn't

AllanJude when you make sets of configs to customize a freebsd install, do you put ALL config files and settings in it? or just the ones that you change from stock? (add, change, remove)

I mostly try to keep my changes in separate files that get included etc

so I can just lay down the files that change the settings

rather than trying to mess with 'diffs'

some parts are easier (the ones that use the UCL config file language)

or where there are includes

I had a patch for a pet peeve of mine (newsyslog.conf default file size, and default compression when using ZFS), but never finished it

so you just keep stuff you actually change, and tar it all up as a distro, so in a scripted bsdinstall it gets expanded onto base and it's good to go?

why does svnweb.freebsd.org/ports/head/sysut…s/firstboot_pkgs.in?view=markup#l39 have </dev/null? what's that part of the cmd do?

Title: [ports] Contents of /head/sysutils/firstboot-pkgs/files/firstboot_pkgs.in

To satisfy requirement ofs some input.

so without that the cmd would FAIL?

Do not know

why would pkg require some input? why not just take the cmd and do the work?

polyex, See "This is typically useful to detach a process from a tty (such a process is called a daemon)." at This is typically useful to detach a process from a tty (such a process is called a daemon).

polyex, Sorry for the duplicate; second should have been stackoverflow.com/a/19955475

Title: What is </dev/null in bash? - Stack Overflow

why detach? you don't want pkg to run in the bg, you want the terminal to wait

oh

That redirection is guarenteeing that the pkg will be non-interactive no matter what.

And then they are a little silly by piping the output through cat to ensure that the output cannot be a tty either. I don't think that is needed.

"env ASSUME_ALWAYS_YES=YES pkg bootstrap -f | cat" doesn't have the </dev/null, why not?

polyex, File a PR to bring consistency?

That does seem inconsistent. But it is also slightly different in that those are running the bootstrap action which is known and not installing any of the package list.

And the same for the update action. Meanwhile it might be that some package in the package list causes an interaction.

oh

how would you make those commands rwp?

The packages list comes from firstboot_pkgs_list and is not in that file and I don't know what would specify it from looking.

Make those commands? update and bootstrap? Those are in the pkg source.

There are (at least) two distinct pkg commands. One is in base at /usr/sbin/pkg and the other is the /usr/local/bin/pkg port.

how would you write the bootstrap and install commands if different from how they did in that file?

Even though the scripting style in that is such that I don't like it I am not sure they NEED to be written differently. That's been there since 2020 and proven to work. Best not to thrash it.

Since there are several commands all getting piped to |cat to make the output a non-tty I would probably really examine if that is needed.

If so then I would probably make a command list with {\n stuff\n stuff\n stuff\n } |cat so that the entire list is output through the non-tty pipe.

But I don't think that is needed.

tyvm

And since the entire thing is meant to be non-interactive I would "exec </dev/null" to redirect file descriptor 0 from /dev/null through the entire script without needing to do it on each command.

But again what's there is proven to be working so I would be hesitant to make a modification which is just there to pretty something.

how can we add a user, all in a 1 line command, and pass a password hash instead of password?

I don't think it is possible to do that in one command. Why is one command a requirement? Do it two commands.

Regardless the "pw" command is the utility to look at if it can be done.

what's the 2nd command that sets the hash of a user's pw?

I am not sure of the BEST way. Someone here might know. I would probably create the user. Then I would edit the /etc/master.passwd file (using vipw and setting EDITOR).

ah

The EDITOR variable can be set to a script (or perl one-liner) which edits the file. Can set the hash with it.

Then when the file is saved and $EDITOR exits the vipw tests the consistency of the file. This prevents an accidental mangling of the file for some types of errors. It's still possible to mangle it so be careful.

Then after the file is updated vipw calls pwd_mkdb(8) automatically to update the /etc/spwd.db file so that it is updated.

why not use sed to search/replace in the file?

You can use sed or any scriptlet you wish to edit the file through EDITOR. It's up to you. Note the 1-second rule as noted in the man page though.

oh wow ty! good catch

It's also possible to edit the /etc/master.passwd file directly and then call pwd_mkdb afterward. That's fine too.

does zfs timestamp with subsecond time?

i wanna script this so i can't do it manually

interactive

Yes. zfs has sub-second time resolution.

so i don't need to sleep?

You know that is probably true. Could verify that by looking at the source code. But I think you are correct. That note is probably no longer needed on newer file systems.

Recently someone mentioned on the lines of that computers are now too fast for proper software function

imo code just needed to be updated. i've been bit by FS not having precise enough timestamps

another OS not even freebsd

I looked up in the source: cgit.freebsd.org/src/tree/lib/libutil/pw_util.c#n344

Title: pw_util.c « libutil « lib - src - FreeBSD source tree

It checks for sub-second resolution if it is available.

Though perhaps even though I suggested vipw as that is a time honored way since it semaphores editing of the files it is probably also okay for most situations to simply edit the master file directly and then update from it.

Such as when a new VM or system is being provisioned and deployed since at the time of creation there isn't any other agents fighting with you for provisioning it. It's just yourself.

parv, You are right about that. Though in this case I am not sure I like that vipw uses a time modification to indicate editing. Since that is not foolproof. (Because fools are too clever!)

ya should be a file hash

but then where do you store the hash

in memory

On line 302 the process forks and the parent waits while the child edits. The hash could remain in the parent's memory.

But then people would argue over which hash to use, md5, sha1, sha256, sha512, zebrapeartrain37 (yes I just made up that last one) so this would still not solve the problem but just move it around.

why doesn't pw take a pw hash as input to create a user with? seems so stupid man

my server has a user account i ssh in with a key file. can i configure sudo to work the same way somehow? then the user account wouldn't need a password at all

polyex: i would configure ssh so that root login with ssh key is allowed, or you could set NOPASSWD in sudo for that user

how's that answer my question? confused

polyex: then i did not understand what you want

sudo does not take ssh keys

pooooo

when installing a pkg during scripted bsdinstall, the dep readline when it's being installed outputs some errors. /bin/sh: indexinfo: not found (repeated 3 times) and pkg: POST-INSTALL script failed. what's going wrong?

polyex: how exactly are you installing it?

and do the logs say anything more useful?

env ASSUME_ALWAYS_YES=YES pkg install bash bash-completion sudo unbound < /dev/null | cat

dunno how to access the log

what's the point of < /dev/null | cat?

ppl said it was good to collect output so nothing gets hung

smth like that not sure

polyex: next time someone says stuff you don't understand, please ask for clarification…

sry

i tried to understand

I think what folks are saying might be related to freshbsd.org/freebsd/src/commit/c0e…9d32c780ee8240fe8b3b8144078a8eec41f and the bug linked from there, but i can't be sure

Title: FreeBSD / src / c0e249d / bsdinstall: avoid conflicts with fd 3 - FreshBSD

bugs.freebsd.org/bugzilla/show_bug.cgi?id=273148 scathing review of a commit

Title: 273148 – [PATCH] scripted installs are unable to verify checksums for fetched dists

but either way, it seems rather strange. i can't figure out what | cat will, that its absence won't. probably buffet? also, what's the point of </dev/null?

you think those bugs are related to my prob?

i'll just take both off

I don't know. certainly not to your readline issues

it just makes the code hard to read / understand, when it's sprinkled with random cargo cult ritual invocations, that probably don't do much, and if they do, it's not documented

for an outsider (say, you yourself in six months from now) it's like watching a cargo cult unfold in a language you don't speak, so you try to piece it together, but it's in vain

WTF

i left the | cat but took out the < /dev/null and no pkg error loool

cool cool cool

you're so right about this cargo cult stuff

I figured out one error

Title: pkg: POST-INSTALL script failed | The FreeBSD Forums

you want to pkg update before your pkg install

ya same prob but they didn't say the solution

amazing that you found that btw

which search engine you use?

🦆🦆 go!

lol

wait maybe it didn't work wtf

first off, instead of </dev/null you could pass -y

ya taking all that off, still fails

damn

polyex: yes, but how does it fail? does the failure mode change?

GOT IT!!

needed to add /usr/local/bin|sbin to $PATH, like the link you posted said

Title: pkg: POST-INSTALL script failed | The FreeBSD Forums

so that fixed that

gonna try to fix bash issue now

in a scripted bsdinstall, i pkg install bash then i try to pw useradd ... -s bash and that errors, but pw useradd ... -s /usr/local/bin/bash works. can i make the former work somehow? man page strongly recommends not using the path form. (pw: no default shell available or defined)

which bash returns /usr/local/bin/bash as expected

just before pw ... -s bash says that error wtf

no you can't

what?

oh

why not?

polyex: pw only allows stuff to be set as shell that exists in /etc/shells

it's in there

Title: shells(5) - FreeBSD Manual Pages (Dev)

it's not. /usr/local/bin/bash but not bash

what?

i can pass -csh so why not -bash

that's a great question

do you have /usr/local/bin in your path?

yep

consisting of the shell's path, relative to root. -- whoever wrote this needs a whack on the head

Title: 274233 – shells(5) is unnecessarily obtuse and lacks examples

polyex: i'd have to look at pw's code to figure out why it's refusing that

imo i'd say path to the shell

meena you know how to do that!?

path is ambiguous

yes, I'm one of those people.

then absolute shell, but TO the shell, not OF the shell

because a shell can have a path, the path within a session of the shell

but a path TO the shell makes it clearer you mean the binary of the shell

Title: freebsd-src/usr.sbin/pw/pw_user.c at main · freebsd/freebsd-src · GitHub

wtf

is no default shell available or defined only in 1 spot in all the code?

then we know for sure where it's coming from

how do we run sed on master.passwd since we gotta go through vipw to do it? like sed "s/foo/bar/g" vipw > vipw?

polyex: what are you trying to achieve?

and why can't it be done with pw?

i wanna set the hash value of a user's pw

i'm only given a hash not the desired pw

meena ^

cat hashed passwd | pw usermod name - H 0

echo -n hashed_passwd | pw usermod username -H 0

Title: cloud-init/cloudinit/distros/freebsd.py at main · canonical/cloud-init · GitHub

WOW

WORKS!

would be cool to get proper cloud-init support for bhyve, but i haven't had time for that yet

ya that would be amazing!

unfortunately I am only as well skilled as I am paid

i hear that

sed "s/foo/bar/g" file > file empties the file out, so what's the RIGHT way to search and replace in a file?

sed -i'' "s/foo/bar/g" file

-i" ?

ya that doesn't wor

k

man-dev.freebsd.org/sed.1#i / man-dev.freebsd.org/sed.1#I

Title: sed(1) - FreeBSD Manual Pages (Dev)

ah, maybe leave space

tried that didn't work

as per examples below, and anyway, saying "that doesn't work" is extremely useless for people trying to help you

"here's the error message i get when i try that: <insert error message>" is a lot more betterer

got it!

ty

if i won't ever use a mouse with this server can i block ums0 from loading or would that block usb keyboards too?

if ums really is just mouse driver like man pages say, then it shouldn't effect on anything else, i would presume

any way to know for sure? i only have the server in a bhyve guest no way to hook up a physical usb keyboard

just doing vnc into it

maybe you can tell bhyve not to create a mouse

yes! how?

morning

re bhyve mouse: No idea.

can someone help me to debug why freebsd 13.2 hangs on xhci initialization on aarch64? qemu/sbsa-ref platform

xhci0: <Generic USB 3.0 controller> iomem 0x60110000-0x6011ffff irq 2 on acpi0

xhci0: 32 bytes context size, 32-bit DMA

and hang

works if I remove that controller from system at qemu/edk2 level but that's not the solution

sounds like a bug…

meena: netbsd 10 boots, openbsd boots

hrw: any chance you can try 14.0-BETA or main to see if it's we fixed this and just need to backport?

and I have *BSD week and already found a bunch of bugs in places

meena: jsut give me url to iso

have you submitted them?

CD/memstick, or VM image?

it was qemu bug (working on it), netbsd bug (backport needed)

CD preffered

will try with download.freebsd.org/snapshots/arm6…21-febba4622b60-265435-bootonly.iso

oy, yeah, good enogh

xhci0: <Generic USB 3.0 controller> iomem 0x60110000-0x6011ffff irq 2 on acpi0

xhci0: 32 bytes context size, 64-bit DMA

usbus0 on xhci0

works

and gets hit by qemu bug later

what qemu version are you testing on?

HEAD

freebsd 14 behaves like 15 - fine

fedora.juszkiewicz.com.pl/sbsa-ref has firmware images

Title: Index of /sbsa-ref/

I'm happy to hear that 14 works, so let's open a bug report and find out what's going on

you can probably cc manu@

meena: paste.centos.org/view/ee5a0b8e is bootlog with qemu command

Title: UNTITLED - Pastebin Service

note: I do not run freebsd on any of my systems (trunas box does not count)

ok, account created, time to report bug

Title: 274237 – boot hangs on initializing XHCI controller on SBSA Reference Platform

\o/

will end with yet another backport probably

meena: I am writing blog post about my "*BSD week on SBSA ref" and try to mention anyone who helped. How to mention you? By ircnick 'meena'?

Mina Galić (meena on IRC)

thanks

of if people use social media, @meena⊙cc ; but I'm definitely way more on IRC than on Mastodon.

@hrw⊙soc

What programs do you use to look on network traffic

...of a specific process

tcpdump if you want to capture things, termshark or wireshark as a tui or gui for inspecting the pcap data

debdrup, *hypothetically* if you wanted to see the contents of traffic (shell commands, output) of a docker client connected to it's daemon via localhost what program would you use :)?

dtrace

Thanks!

dtrace is the only way to inspect the entire system

debdrup, ...

by traffic I meant network traffic

yes, i get that

dtrace can trace things from userspace all the way to the data exiting out the kernel to the actual device

so it's not a joke?

why would it be?

no idea, anyways the problem I am having is that running one docker command displays no output, I quickly want to check if the docker daemon is even sending that ouput to the client and the client is just not displaying it correctly

i'm not sure why you're asking about docker in #freebsd

the output is just text

debdrup, could you atleast elaborate on how you would use dtrace pls :)

i'm not sure what you're asking for

how do i make an rc.d script run as a different user than root

bz: maybe setting suid on the file and setting the file's owner to that user would do it

I'd test it first though

that specifically does not work

there are *_user= variables that you can set in the rc.conf or default in the file - note that those are only used for part of the process

Hi all, wanted to ping here before opening a bug report. FreeBSD13-2 | `pkg audit -F` isn't showing any vulns, but `pkg upgrade -v` identifies two vulnerable packages. This is the case on a handful of systems I maintain.

is /var/db/pkg/vuln.xml up to date?

@RhodiumToad, pkg update reports it is.

does it have a suitably recent timestamp, etc?

3 Oct 13:40 UTC

shrug. pkg audit -F seems to be working for me

what packages?

cyrus-sasl-2.1.28 and p5-IO-Socket-INET6-2.72_1

Did the vuln database get updates for those?

The last cyrus-sasl was for 2.1.27 so .28 is good. Something new come out for either one?

I don't see the IO-Socket one anywhere?

I don't see anything published for the installed versions.

what is the best channel for asking vagrant-on-freebsd/bhyve questions?

Here's the output. Maybe I'm misinterpreting the "vulnerability found" statement? pastebin.com/gnZZmcWG

Title: pkg audit -Fvulnxml file up-to-date0 problem(s) in 0 installed package(s) fo - Pastebin.com

pkg info p5-IO-Socket-INET6 shows what version?

2.72_1

so I don't see any reference to p5-IO-Socket-INET6 in recent security/vuxml updates, and I don't see any recent updates to the port

so where on earth is it getting the idea that it's vulnerable?

good question! I appreciate the sanity check.

Do you have multiple repos?

On some hosts, but not the ones exhibiting this behavior.

I remember seeing a malformed items in vuxml the other day. Wonder if it's related.

So everything in UPGRADED list is there because of a vuln?

er no... pkg-audit returns nothing.

pkg upgrade -v should only upgrade vuln packages.

yeah, pkg audit returns nothing. The upgraded list must have a dependency relationship.

That's my understanding. According to the manpage, -v should target vulnerable packages.

as i search around for how to use ZFS send and receive (haven't read the man page yet, but will), i have pretty much only found how to send local to remote. local for me is a VPS, though, and i want to send it to my home. i don't want my vps to phone home though. i want my home to reach out to the vps and pull a snapshot home. anyone have a link for a short writeup on that? i'm not worried about automation yet. just a one-off

zfs send just writes to stdout, so there's no problem

i'm not enough of an ssh guru to understand the mechanics of that. presumably there needs to be zfs receive running at home that awaits the a zfs send triggered on the vps by an ssh connection from my home, and maybe the send gets piped back through that same connection.... but it'd be nice to see an example :)

ssh -n remote zfs send ... | zfs receive ...

Is there way to search the ports tree without running BSD or digging through the github?

the freshports website?

Title: FreshPorts -- The Place For Ports - Most recent commits

By architecture? I'm trying to play with some PPC and SPARC hardware, and from recollection PPC had more support lol

i imagine i will realize how simple this is once i turn that into a working example. thank you!

iirc, sparc was deprecated in fbsd 13

deprecated in 12, removed in 13

powerpc is still supported afaik

yeah, ppc should be in reasonably good shape. ppc64el was recently-ish added, and its almost certainly better supported in the ports tree than ppc64 or ppc32

what's el stand for?

little endian

well I guess endian little :)

sigh

I thought that's what it means……

whoops

i always screw up the word ordering :-)

it was mipsel, mips64el

armeb

ahhh, so I'm not crazy. I was only coming up with armeb as for a plausible explanation as to why

I guess jhibbits just thought it was a silly tradition and went with powerpc64le

(I think it was jhibbits)

i suspect not, he's pretty pro-BE

or at least, he was the last time I remember him talking about it

I have the same repo on gitea and Github. I've done a pull and push to each origin, but they don't have the same tags yet. Not sure how to fix that. github.com/FreshPorts/packages-import/tags vs git.langille.org/FreshPorts/packages-import/tags - thanks

Title: Tags · FreshPorts/packages-import · GitHub

dvl: git push --tags (or even --all)

meena: Thanks. Something is happening

All kinds of new tags which I'll need to clean up. git.langille.org/FreshPorts/packages-import now has 287 tags. ;) but it has the one I need right now.

Title: FreshPorts/packages-import: Code for importing packagesite.yaml information into FreshPorts - packages-import - Dan's git collection

meena: It is expected that 'releases' didn't go over too?

what is the best channel for asking vagrant-on-freebsd/bhyve questions?

dvl: i don't know what releases is, so I don't know

meena: I suspect it's a github/gitea specific thing

can we tell bhyve to not create a mouse?

dvl: yeah, that would not surprise me

kevans: I can get tags copied from GH to gitea, but not releases. No big deal so far.

I think there's a special github importer that would probably do the trick, but releases are a concept tacked on top of git

much like pull requests & issues are tacked on top

Title: Testing *BSD on SBSA Reference Platform – Marcin Juszkiewicz

polyex: how are you creating VMs right now?

bhyve -AHu -c cores... -m ... -w -s 0,amd_hostbridge -s 1,virtio-blk,/dev/zvol... -s 2,virtio-net,tap...,fbuf,tcp...,w...,wait -s 30,xhci,tablet...,lpc -l bootrom,...uefi

omitted stuff that seemed obviously irrelevant with ...

hope that's ok meena

hrw: ah nice, we also surfaced a problem in qemu, though it doesn't seem clear yet if we're doing something we really shouldn't be?

kevans: that AHCI one?

kevans: it was this thread: lore.kernel.org/qemu-devel/20230609140844.202795-1-nks⊙fo

Title: [PATCH v3 0/8] misc AHCI cleanups - Niklas Cassel

kevans: if it worked before this got merged (QEMU v8.0.3) then I would compare with v8.0.5 when it was present.

kevans: lore.kernel.org/qemu-devel/b7e00b36…8-44fa-9847-b2025ebe05f6⊙lo is a thread where I pointed out that somethign went wrong

Title: FreeBSD 13.2 installer does not see AHCI devices on aarch64/sbsa-ref and x86-64/q35 - Marcin Juszkiewicz

in a scripted bsdinstall, i pkg install bash then i try to pw useradd ... -s bash and that errors, but pw useradd ... -s /usr/local/bin/bash works. how can i make the former work somehow? man page strongly recommends not using the path form. (pw: no default shell available or defined) which bash returns /usr/local/bin/bash, and that path is in

/etc/shells.

hrw: right, the question is if we're expected something that's common-place but not in the spec vs. are they doing something that's actually out of spec following that change

s/expected/expecting/

kevans: no idea. I was glad that it happened also on Q35 so it was no longer architecture related bug

kevans: I am rather trying to make my tickets list shorter ;D

eheh :-)

Niklas wrote that we will look at it so it is in his basket now

I have the hagios4 package installed, but it's got various problems... like no config file, no samples, other complaints... right now I'm trying to beat configs from slackware and/or debian to make them work, and it's not going well

Hi there! Anyone installed 14's beta4?

mtwk: many people have!

meena: ah!

I'm currently installing blued because hcsecd doesn't work with my headphones

Hmm, quick opinions...if I have a tarball that is digitally signed, would you store the signature inside the tarball or alongside the tarball as a separate file?

alongside like freebsd releases have? the installer iso img file, then the checksums file?

Specifically, this is for an archive that contains a ZFS dataset snapshot and some text files (e.g. jail.conf template).

Kind of, but not just a checksum. I'm using a digital signature that can be verified via public key (which the target system will have).

if you're hashing a tarball and storing the hash file inside, how do you correctly calculate the hash?

if the sha256sum changes every time the hash file inside the tarball changes

Well, couple of ways. You can store a list of signatures for the contents of the archive (instead of the archive itself). You can also store a tarball within the compressed archive, and then keep the signature for the tarbell as a separate file within the archive.

I'm leaning towards keeping them separate since it would be simpler and also because I can fetch the metadata text file (which is where the signature would be stored), and store additional info within that to possibly cache the archive.

well if you're going to do that then ya i'd have an inner and outer tarball

resources inside first layer

In which case the target system can decide whether or not it actually needs to download the archive or not (if it's already cached).

It's basically how docker does it's images, except it uses file system tarballs with white-out files rather than ZFS image + snapshots.

By "except it", I mean docker (or more specifically, OCI) does it using file system tar archives.

nice

why do zfs image + snapshot instead of file system method?

Gah, I wish OCI had been a bit more flexible to begin with. Would be much nicer to be able to leverage the existing ecosystem there and still be able to use ZFS.

Because ZFS image + optional snapshots is more efficient and also doesn't require whiteout files.

Also, it would essentially be impossible to accidently apply the layers in the wrong order. Tarballs you can just extract into a directory and it won't complain. ZFS snapshots can't be applied out-of-order.

what's a whiteout file?

Also, I have the option of setting zfsprops on the dataset. Doing that with the file system tarballs would mean keeping that in a separate metadata file and handling those appropriately.

A specially named file in a directory that basically tells docker, "Hey, these files were deleted..."

oh

so instead of doing an 'install', you do an image copy of a fully configured system right into place?

If I'm understanding the question right, then yes basically.

that's like next level automation and efficiency even beyond scripted bsdinstall

Docker/OCI images are immutable, so you can't just delete a file from a layer in volume and keep it immutable. Instead you have these specific whiteout files scattered about as necessary that tell Docker/OCI which file(s) were deleted in a specific layer that exists in a previous layer.

It's common with containers. I'm doing the same thing, except with jails.

Though I think I have a bit of an advantage on the ZFS + Netgraph front. On the flip side, rctl isn't as fine-grained as cgroups+namespaces.

hrw: yeah, more than happy for him to evaluate the change he made and either fix it or point to something specific we must be doing wrong

Hi guys, i guess some of you already heard of CVE-2023-4911 / qualys.com/2023/10/03/cve-2023-4911…rivilege-escalation-glibc-ld-so.txt - I'm assuming, that FreeBSD isn't vlunerable as they use an own libc Implementation. Correct?

danel1: correct. freebsd libc and glibc share no code

danel1: we share some features, but no code.

that makes my evening much better :-P

Woohoo!!! i.imgur.com/pQkwXoO.png

I do prefer FreeBSD over Gentoo now :)

I'm confused. i.imgur.com/XN7NZ5A.png

So, does dsp0 exist or no?

do we have quantum block devices now?!

character*

how do i non-interactively edit a sudoer file? we're supposed to use visudo but how do we do that with another program?

you can just edit /usr/local/etc/sudoers with any text editor

ya but not supposed to

same with master.passwd

there's locks and syntax checking

nothing bad will happen

if you don't mess anything up

k ty but i'll do it right instead

visudo just runs "vi /usr/local/etc/sudoers" as i know

i'm not doing it your way, ty

what is the best channel for asking vagrant-on-freebsd/bhyve questions?

meena, Regarding "< /dev/null | cat" that's from cgit.freebsd.org/ports/tree/sysutil…ot-pkgs/files/firstboot_pkgs.in#n38 where it is used there. I surmise it forces a non-interactive installation.

Title: firstboot_pkgs.in « files « firstboot-pkgs « sysutils - ports - FreeBSD ports tree

I think the </dev/null is probably reasonable helping to force a non-interactive install but I question the need for |cat to force stdout not to be a tty.

polyex, I strongly suggest NOT _editing_ a sudoers file. Instead place a full file in its entirety such as /usr/local/etc/sudoers.d/sudoers in the sudoers.d directory avoiding the need to ever edit or merge with it.

rwp ya that's what i'm doing. -f

oh, ever needing to edit it

hmm

The last line of the standard sudoers file is "@includedir /usr/local/etc/sudoers.d" which includes all files from that directory into the combined configuration.

ya i guess i don't ever need to edit the main file, i can just drop files in the .d

i need to get those files edited right first

Yes. By completely owning a full file in that directory it means it never needs to be edited.

You can also have several files in that directory if that helps things too.

I keep one file for most of my systems. But some systems additionally get additional files with additional configuration specific to that system and stuff there.

i have to set the file's perms so visudo doesn't complain

Permissions and ownership should be correct there regardless. visudo is simply going to enforce the rules of sudo. But you can do it yourself too.

ya so i have to manually change the .d/* file perms right?

In times before @includedir existed it was necessary to combine all of the configuration into one file. Which means merging. But after @includedir exists it is much easier to maintain separate files and never modify the main /usr/local/etc/sudoers file ever so that it never needs to be merged.

When you say "change" the permissions I would say "create the file and set the permissions" appropriately. That's standard for so many things in the system that isn't that just the standard operating procedure for everything?

oh so if i set perms on a file, tar it up, uncompress into a freebsd install, the perms will stick? wow cool

This is the first I read you mentioning tar but maybe you said it before and I missed it. Yes. tar will preserve users and permissions and if unpacking as root (superuser permissions to do anything) then it will set the file owner:group:mode as from the tar file.

Note that in BSD the group of the directory normally sets the group of files created in the directory. On other operating systems that behavior requires the set-gid bit ('s') to be set.

Normally non-root users unpacking a tar file do not have the ability to set the user:group outside of themselves. But of course the superuser can.

In the tar man page please see the section "-p, --insecure, --preserve-permissions" for the documented details of this behavior.

Which do accurately describe the behavior but if you want the rationale and the why behind this then wind me up about it and I will write some article on it.

i get wrong owner (uid, gid) should be (0, 0) on the files in the .d/. gonna have to figure that out

What user is unpacking? root? What user:group was packed up? "tar tvf file.tar" to see the content Table Verbosely.

ya root

just a regular user on another box

k sec

looks like my user/group is on the files in there?

any way to strip that out so the tar is clean of that?

The tar bundle was packed up that way then. Was the machine you packed this up on a Debian-like system? (I think I heard that earlier.) If so then pack it up using "fakeroot" there.

no freebsd

Then install fakeroot there and use it.

tar -C dir -cJvf dir.txz .

that's how i made archive

"pkg search -f fakeroot"

do i have to use that?

No. But it is convenient. It's a way to have files on disk be owned by non-root but have them bundled up into the archive with a root owned listing.

Okay. Strike most of the above. After unpacking simply "chown root:wheel /usr/local/etc/sudoers.d/sudoers" your file. Then "chmod 0440 /usr/local/etc/sudoers.d/sudoers".

Thinking somewhat more "chown 0:0 /usr/local/etc/sudoers.d/sudoers" is probably better because it is more portable across systems. Other systems use gid 0 but use a different name than wheel. Avoiding the name and using the number would work all places.

k trying now

ya that worked

i added chmod 440 .d/* files

visudo -c passes now

ty!!

in a scripted bsdinstall, i pkg install bash then i try to pw useradd ... -s bash and that errors, but pw useradd ... -s /usr/local/bin/bash works. how can i make the former work somehow? man page strongly recommends not using the path form. (pw: no default shell available or defined) which bash returns /usr/local/bin/bash, and that path is in

/etc/shells.

hm. in my system setup script, I do pw useradd ... -s zsh and it works

what error did you get?

I read the man page for pw, see that warning, and also it says shellpath is set in /etc/pw.conf which I do not have on my systems. Perhaps that is needed in order to use the short name rather than the full path?

aha

shells = "sh","csh","tcsh","bash","zsh"

and shellpath = "/bin:/usr/local/bin"

my setup script edits those into pw.conf

specifically it does:

touch "$DESTDIR/etc/pw.conf"; pw useradd -C "$DESTDIR/etc/pw.conf" -D -u 1000,3999 -i 4000,9999 -s sh; ed ...

I tested a few things and I think by default shellpath includes /bin but does NOT include /usr/local/bin and therefore does not allow using "-s bash" by default. Requires shellpath to add /usr/local/bin

Just as a side comment, in order to support #!/bin/bash scripts (blech! I hate those. But there are some.) without editing the script I create a symlink /bin/bash to /usr/local/bin/bash to pragmatically allow those to work.

Same thing for #!/usr/bin/perl too.

I just change the first line to be env

I would be needing to locally patch a lot of other people's code that I would prefer not to touch. I would get cooties from it I am sure. I know my eyes would bleed.

but… shouldn't #!bash work just as well?

I assume you are teasing me now! :-)

I mentioned that because for me with /bin/bash as a symlink using pw -s bash "worked" but I got /bin/bash in my passwd entry.

When I removed that symlink for the test then pw -s bash then gave the expected error. I had to set the full path in that case.

so create your pw.conf as detailed above

Also the man page for older classic chsh says that the path must match the path in /etc/shells implying one would always use the full path with chsh.

polyex, See what RhodiumToad said ^^ there. (It's not me it's polyx.) :-)

cgit.freebsd.org/src/tree/usr.sbin/pw/pw_conf.c#n308 shows that the compiled in default shellpath is "/bin".

Title: pw_conf.c « pw « usr.sbin - src - FreeBSD source tree

do we have to put rbash and nologin into the shells = line in pw.conf or are they implied?

i'm adding a pw.conf now to see if that lets scripted bsdinstall pw add a user with -s shortname

ty so much RhodiumToad and rwp

boo

I don't feel like doing a freebsd-update today

i never do them i just reinstall

that's fair

I've started it on my backup server

RhodiumToad ok that worked!!! i can pass -s shortname in scripted bsdinstall

polyex, How are you installing bash? Because a "pkg install bash" will automatically add bash and rbash to /etc/shells.

rwp ya same. but that doesn't add them to pw.conf

btw adduser still ends up showing nologin, so pw.conf shells = "..." doesn't have to include nologin

Meanwhile... Word of advice. Never use rbash or any of the restricted shells. They are mostly security theater being too hard to actually secure and too easy to miss something making it trivial to break out of them.

ya i just use csh on root (till it changes to sh in 14) and bash on user level. that good?

polyex, So in the grand scheme of things pw is a new thing. Previously users would use chsh and that always required the full path. (And sysadmins would just edit the /etc/passwd file directly at that time and set what they wanted.)

well i'm using pw because that's the only way i found to change the ENCRYPTED pass of a user

Of course that's fine (re csh, tcsh, sh for root). Note the presence of the "toor" user (root backwards) that can be enabled as an alternate root login account. I tend to use it.

that's being removed in 14

or 15

A lot of these things that exist by default or don't exist by default just exhibit the "tyranny of the default" but they are all things that can be changed by the local sysadmin. Let defaults be a guide but don't let them restrict you.

For me I can use csh, tcsh, sh, ksh, and others okay no problem. (Did I leave out zsh? Yes. Good.) But my fingers do know bash keybindings strongest. So I prefer to use bash.

But bash is in ports not base. When going through a major upgrade base will change EVERYTHING. Or at least might change everything. Which has in the past broken ports. Ports like bash.

I snagged myself on an upgrade previously where I had changed root's shell to /usr/local/bin/bash which would no longer work and left me without any way to log into the system by any user account that existed. It was self-inflicted of course.

So now I leave root as the default base contained csh or sh or whichever it happens to be okay. No problem. Then I enable and modify toor to use bash and then log into the system using it.

ya i never change root shell

That way if I break a port shell again I can still fall back to the default root shell and all will be okay.

ya

Some people choose to do the opposite. They will enable the toor user and leave it using the base shell and then modify the root shell to use a port shell. It's the same thing. Just reversed. That's fine too of course.

Meanwhile... I use zfs so of course Boot Environments exist so I just rebooted and booted to the previous Boot Environment and then fixed up the new Boot Environment root shell and then rebooted again and had the problem fixed in the time it took for two reboots and one file edit in the middle. Boot Environments ROCK!

And then could finish the major release upgrade.

man i can't wait to figure out how to start using boot envs

after install, why don't i got scripted bsdinstall's log at /tmp/bsdinstall_log like man bsdinstall says it should? or is that only during install then it gets deleted?

even when i try to cat it in my scripted bsdinstall it's not found

like a month ago someone was here with a broken /bin/sh from a freebsd-update

WHOA

how is that even possible

a broken update is usually unpredictable

cool benefits of rescue environments and backups

polyex, /tmp/bsdinstall_log? I was unaware of that path. Are you clearing /tmp on boot like I am?

ya but it's not even there DURING scripted bsdinstall

No idea. Browse through /usr/sbin/bsdinstall (it's a shell script) and see what it is doing?

Looks like "debug" needs to be set. From a quick look.

is that in /tmp on the install disk or the target disk?

I think it would be in the install disk system not the target disk system.

how do i make scripted bsdinstall set debug?

Anyone else getting dup FreeBSD Sec. update emails?

I just get a digest :\

thedaemon: icumi bugs.freebsd.org/bugzilla/show_bug.cgi?id=274211

Title: 274211 – lang/tcc: Crashes with SIGSEGV on 14.x / 15.0-CURRENT when compiling hello world

in a scripted bsdinstall, how do we set the system timezone? just tzsetup UTC?