polyex, Which logs? messages? Or auth.log? messages is already 644, right? But auth.log is 600 due to the sensitive nature of it.

If you are the only one on the system and it is on the LAN not WAN then that seems acceptable. I wouldn't do it on a public server machine because it might be used as a chain to something else if there is a first exploit.

daemon logs like postgres

I am not familiar specifically with postgres but that seems like it would be reasonable to be 644 there.

Another frequently configured way is to make the group of the logs readable by group wheel or a group like adm and then add yourself to that group. Then you and only you can read the logs easily by group permissions but other users are not allowed.

To change the group of a logfile of course the /etc/newsyslog.conf file can list the user:group in the 2nd column for that logfile and set the mode to 64something.

tyvm

This is what I get when I run liquidsoap -h icy.update_metadata (in a jail, in a non-root user shell running bash) (it's filled with escape codes) bsd.to/O5W7

Title: dpaste/O5W7 (Plain Text)

it would be nice to understand the cause. it seems they have some sort of colored log. maybe the pager (on this box that has no X or anything on the host or in the jail) is expected to behave differently

VVD: blender builds on BE after all

why are so many rc.d files 655? they should be 555 i think

like rsyncd

should rc.d scripts have "networking" or "NETWORKING" for the REQUIRE: field?

got thinkpad t480. now install time

polyex: NETWORKING, but whether it's case sensitive is not documented

at least not in rcorder(8)

Gotta be uppercase

des@ vs /usr/sbin/adduser. FIGHT!

dch why does it gotta be uppercase? because it's a special purpose symbol and not an actual rc script name?

lw in man rc there's a "ALLUPPERCASE" about these virtual REQUIRES items

it's not exactly virtual

-r-xr-xr-x 1 root wheel 287 Apr 15 22:04 /etc/rc.d/NETWORKING*

s/virtual/dummy

if you want to ask why it's uppercase you probably need to take that up with lukem

my hostname is changed but not in my /etc/rc.conf

changed to "ConnectOn" but I have no idea why.

also, is there a way to disable starting firefox as certain users?

entikan, Generally speaking if the hostname became "ConnectOn" then I would look for that string because I suspect "hostname [options] ConnectOn" was applied somehow.

Back on HP-UX which does not support any options it was pretty common for people to run a script and their hostname would become "-f" due to the linux world's proclivity to use "hostname -f" to read out the hostname as a FQDN by reverse DNS lookup. It happened quite a bit.

entikan, Re: blocking users from running any particular program. Generally no. Because a user can always simply copy in a program from elsewhere.

One could remove programs from the system. But then I could always copy that program in from elsewhere into my home directory and run it from there.

grepping the whole disk for "ConnectOn" doesn't show anything. But it did happen after logging in to someone elses router. Perhaps it happened there?

Or I could compile the source code and have a natively compiled executable.

By some chance is the host setting the hostname to the reverse DNS for the IP address that it was dynamically assigned by DHCP?

That always seemed crazy to me but RHEL/Rocky/Alma/CentOS do exactly that! It's an unreasonable configuration to my sensibilities but they do.

rwp: That's fine, it's just for myself. I need firefox for some administrative purposes but I'd rather have some hoop to jump through for before it starts up (logging into a seperate user for it for example) or I get sucked into old habits

how do I check the reverse DNS?

If it is just for you and you want to restrict an executable to some particular user then chmod go-x,u+x and it will be executable only by that user that owns it, and then set the owner to the user you want to be able to execute it.

Or alternatively the same thing using group permissions. Actually... Using group permissions for that is probably more sensible.

Using one of "host", "dig", or "drill" look up the IP address. For example looking up "host 142.250.72.69" here says "69.72.250.142.in-addr.arpa domain name pointer den16s09-in-f5.1e100.net." (That's mail.google.com by the way)

I'll try that out next time I'm logged into that network, thanks!

and I'll look into group permissions, this is very helpful yaaay

For dig it could be "dig -x 142.250.72.69 +short" and for drill basically the same syntax as dig almost always.

do not dig

omg what will you find

there could be anything down there

if god wanted us to dig we would have been born with /usr/bin

Hi.

I need to truss a command. How can I avoid following error?

truss: Unable to enable LWP events for pid 99999: Operation not permitted

Which permissing I've to grant to this user to be able to execute truss?

s/permissing/permission/

lw, If dog wanted us to wear clothes we would have been born that way! :-)

security.bsd.unprivileged_proc_debug is enough?

github.com/freebsd/freebsd-src/blob/main/sys/amd64/conf/NOTES ---- from 'CPU OPTIONS' , '# Options for CPU features.' is empty. from where i can look up to for avaible choices for 'options for CPU Features' ?

Title: freebsd-src/sys/amd64/conf/NOTES at main · freebsd/freebsd-src · GitHub

hello!

CountryBall0, AFAIK there is only one for amd64 - "cpu HAMMER"

i cant interact with the installer because keyboard is acting funny on a very old hp laptop (from 2006). not a single key is functional, not even arrows, enter, tab... nothing. jsut shift seems to act like enter. any advice? thanks!

ndo-, can you connect USB keyboard?

VVD, below that there is 'options for CPU features' tho and it doesnt listed any options for 'cpu HAMMER' , its blank. what are the CPU feature options for 'cpu HAMMER' tho ? (at sys/amd64/conf/NOTES 'options for CPU features' is blank :/)

VVD: gonna try.

CountryBall0, this part is template - check NOTES for i386.

VVD, yes it seems i386 NOTES file has that 'cpu options' . so from this I should understand as; amd64 has only 'cpu HAMMER' option and no CPU features options as kernel options? (thanks btw for pointing to the i386 notes)

CountryBall0, probably yes.

VVD: its working with the usb keyboard

but if i manage to install the whole thing i'll be stuck with the external keyboard i guess

if my rc.d script needs networking and daemon, i only need to specify REQUIRE: DAEMON right? because DAEMON implies networking too because DAEMON has REQUIRE: NETWORKING

ndo-, try to install using it and after reboot from disk check internal keyboard

VVD: ok thanks

VVD, thanks

I think thats a lot of whst actually bothers me, since i spend way more time tending to BSD and Leenoochs systems from my mac desktop - and Unix just flat out lets you juggle running chainsaws and play russian roulette with a semi auto if you want... so getting nerfed on stuff on my desktop stings

.

VVD: ok, installed

VVD: no internal keyboard, same behaviour

what's better style, cmd --foo=bar or cmd --foo bar?

polyex, How long is a piece of string? Personally I prefer --var=foo style when using long options.

why?

It just clumps the entire set of characters together visually and I think makes it more visible what is happening.

But "--var foo" is also valid. It's valid so I can't say it is wrong.

ndo-, :-( maybe u have options in BIOS?

VVD: i dont know, i'll just finish to setup DE and then try to investigate

i dont even know what kind of information to look for

Rwp: its as long as the universe needed it to be

ndo-, something about keyboard

btw, maybe u can configre keyboard in DE

any upside to having daemons log to their own log file instead of just dumping it all into syslog?

mrelcee, Right! And since there are likely three different valid forms for -v foo, --var=foo, --var foo, all being valid I think all are valid. But I prefer --var=foo visually.

Various programs have different option processing however. There are a lot of variations.

polyex, Programs which generate A LOT of output tend to use their own log file. nginx/apache dump a lot of output for example and tend to write to their own log file.

It's a judgement call for the program. If something is going to completely dominate a file with output then I would put it into a dedicated log file.

If something is going to occasionally make a log entry like cron or something then using the existing system log framework is most appropriate.

hm

polyex, WDYT?

well just to make monitoring easier, i kinda want to just stuff everything possible into syslog. but i also want to limit logging output to warns or higher severity

Then I say just do it. Often things just need to be done in order to know if it is the right thing to do or not. Then make corrections only if needed.

how do i adjust the msi-x interrupt vectors on my nic? i've been looking at the iflib settings to see if i can gleam where they are but im winging most of it

rwp also i run into probs where i don't know to look in /var/log/messages or in /var/log/mydaemon/mydaemon.log for daemon probs

not like it's hard to check but stuffing everything i can into syslog helps reduce that

got a opentelemetry-collector running as a daemon. it's made in Go. when i run sudo service otelcol restart log file says "Error: failed to shutdown service after error: failed to shutdown pipelines: sync /dev/stderr: invalid argument; sync /dev/stderr: invalid argument". anyone know what that means in Go code?

polyex: but does it otherwise work?

ya

i wonder what daemon even does with stderr

Is that daemon running in a container? Does the container have a /dev/stderr and if so is /dev/fd mounted?

I am one of those people who despise seeing /dev/stderr because it creates this extra dependency that isn't otherwise needed. Just write to fd 2!

ya it is running in a container

Does the container set "mount.devfs" for it?

ls -la /dev/stderr -> fd/2

oh indeed

Right. And therefore /dev/stderr depends upon /dev/fd having been mounted. That's an extra worthless dependency that shouldn't be required.

jail's config has mount.devfs in it yet

ya*

those files are useful for scripts

only scripts

/dev/std*

@files"

"

Well, then /dev/stderr should work. I would jexec into the jail and verify that it works. If so then the problem is somethign else.

how do i verify it works?

ketas, It's only extremely rarely useful in scripts.

opening that in some other code is wtf

polyex, "jexec -l jailname login -f username" (username is possibly root) and then ls -ld /dev/stderr /dev/fd/2; echo foo > /dev/stderr and see if it works there.

well if it's not written to have - thing or separate option, sometimes some util can open stdin "file"

rwp that echo'd "foo"

limited use, yes

ketas, People use /dev/stderr because they read it somewhere and learned about it but it didn't even exist until like 1999 or something.

how do i disable it?

if it's just a hack

is it just a hack or an actual improvement?

<rant mode> So in a shell I want to print an error: echo "Error: this thing failed" 1>&2

1>&2?

polyex, It's just a hack but if that is not your problem case then I would not touch it. Instead your daemon has some other reason it is printing that error message. Keep looking for the root cause of that error.

should i take "mount.devfs;" out of my jail config?

ketas, If you are not a shell programmer then that is gobblygook. 0 is stdin, 1 is stdout, 2 is stderr. echo prints to stdout 1 by default. 1>&2 assigns fd 2 (stderr) into the fd 1 (stdout) so that when echo prints it then prints to 1 which is mapped to stderr.

well 1> works too

stdout is assumed by default...

On the command line both stdout and stderr go to the terminal. So both will appear to "work" such as it is. But in a script if you redirect stdout then stderr should continue to go to the terminal.

The idea is that errors happen out-of-band to the normal flow so that you see them.

sometimes it's annoying too

grep foo file1 | awk '{print$2}' | tr a b | sed ... you get the idea. If any of those print an error then the error goes to stdout and NOT into the stdout going into the pipeline.

have | less, stderr doesn't go there

:p

The order of assignment is important too. That's why if one wants to discard all output it is "if grep foo file1 >/dev/null 2>&1; then" in that order > then 2>&1 and not a different order.

i think most don't use redundant 1>

The first > sends fd 1 to /dev/null and the next 2>&1 assigns fd 2 to the same place as fd 1.

hence wtf

is there a shell that required fd number?

"1>" is just the same as ">" so not really the idiom. It's okay to have it there. It's redundant as you say. But we started of with why one does not need /dev/stderr usually almost never.

AFAIK there has never been a shell that required a number there.

yeah, shells, perl, python, c, they all allow you internal stderr usage

so no idea why

something something easier?

we have urandom too

you don't really need to open that "file"

but i get the idea

it's always there, as a "file"

rwp so that bug is from somewhere else?

got a opentelemetry-collector running as a daemon. it's made in Go. when i run sudo service otelcol restart log file says "Error: failed to shutdown service after error: failed to shutdown pipelines: sync /dev/stderr: invalid argument; sync /dev/stderr: invalid argument". anyone know what that means in Go code?

that 1

What bug?

I guess I don't know if that is a bug yet.

well is the OS working right?

the container

Sure it produced an error message. But neither you nor I know what that error message actually means at the root cause of it yet. I can't say it is a bug yet.

I don't see anything leading me to believe the jail container is not working right.

ok ty

I mean jails have been around for years, are very mature, people run thousands of programs in them, and then this one program is giving an error message. I am more likely to think this one program is where the problem is located.

But until I would get to the root cause of it then I don't know if it is a bug or not.

putting that aside, would you disable the /dev/stderr hack?

like so /dev/stderr doesn't even exist

Nope. I would let the jail mount /dev and just keep moving with it there. It doesn't hurt anything to have it and then programs that use /dev/stderr will work without changes. (Even if I don't like that they are using it.)

ok so your containers have mount.devfs; too?

Yes. I always have those in my jail.conf file globally.

Reading that error message seems like quite a bit of gobblygook to me. "sync /dev/stderr: invalid argument" What's it really doing there? is it calling fsync(2) on the fd and it is producing an error? Perhaps the fd is closed at that moment? Maybe.

ok ty

the app is being run by daemon

Do you have the source to this Go-lang program?

ya it's github.com/open-telemetry/opentelemetry-collector

Title: GitHub - open-telemetry/opentelemetry-collector: OpenTelemetry Collector

Also if run under daemon with -f it will redirect stdout, stderr to /dev/null so that it is a bitbucket receiver. But sometimes I see people /close/ the fd and that could cause an invalid argument error for example as fsync(2) on a closed fd would do that.

my rc.d command line for it is daemon --output-file=/var/log/otelcol/otelcol.log --sighup --supervisor-pidfile=/var/run/otelcol/otelcol.pid --close-fds /usr/local/bin/otelcol --config=/usr/local/etc/otelcol/otelcol.yaml

tried -f and no 0f

hmmm

-f

Hmm... "--close-fds" but that's an argument to opentelemetry-collector, right? So that /shouldn't/ be the problem.

daemon is really cute util btw

no that's to daemon rwp

that's also a hack kind of

daemon is great! :-)

just close fd's and fork off

but then it also catches pids and restarts if needed

When I read the man page for daemon I see no --close-fds listed there. Is that new in 14? I am still on 13.

It's new in 14.

it's same as -f

i'm on 13.3

daemon -f does not close file descriptors though as they are redirected to /dev/null.

I think 14 introduced a bug in that they say --close-fds redirects but then they are NOT closed! BUG! Gack.

It was introduced in 13.3 and 13.2 does not have that option.

This is just one of those examples of things that get worse instead of better. Oh well. Corey Doctorow was right.

# Do we want the config file compiled into the kernel?

INCLUDE_CONFIG_FILE opt_config.h <<--- what happens if we dont compile kernel config file into the kernel ?

ketas, I generally agree that programs should turn themselves into daemons as needed. It's not that difficult. But...

Oh look at the time! I must run off. Good luck!