getz: i've never heard of that before either

where is that documented

what did I miss

that doesn't work at all

my memory served me wrong :)

Im sure it worked on a machine for me, I guess the group already had permissions set up then

do you run some sort of fail2ban etc for SSH? I have ssh on a non-standard port, I get tons of connection attempts still

its on a server that has domains pointint to it, so fairly discoverable

I have root login disabled, and only key login for users

i apparently have 2265 banned IPs on my primary server. Useful stuff

I use sshguard, mainly due to the noise in the logs. But I have locked myself out a couple of times, so you have to make sure the blocklist gets cleared periodically or you have an alternative way in.

what about blacklistd?

I've been using sshguard on my FreeBSD servers and Mac workstations for years. If you accidentally lock yourself out, you have to wait for the timeout to restore your access. However, I also have the whitelist set up to prevent that.

Of course it helps to set up 2FA as well. sshguard is just a second layer.

how is that different than fail2ban? says it also uses logs

freebsd's blacklistd links directly into ssh, not reading a log

I use resident keys on yubikeys, I have several

also, I can log in via the serial web console of my vps hoster

I'm attempting to build a c++ application using cmake, however, it requires libtidy-dev. I have installed `tidy-html5`, which cmake seems to recognize, but then its missing a variable. The software doesn't officially support freeBSD, but I was able to build it before, I think the tidy dependency is new

there error is in the issue I created: Sude-/lgogdownloader #281

I didn't find a libtidy in the ports

well, there is www/tidy-lib, but that I couldn't install from pkg

yourfate: what's the url for libtidy?

the port? freshports.org/www/tidy-html5

I think this should be it

no, the libtidy

thanks

afaik that port is that.

it links there

I have libtidy in /usr/local/lib

from that port

adding `-DTIDY_LIBRARY=/usr/local/lib/libtidy5.so` to the cmake call fixed it.

yep, the port seems to avoid some conflict by renaming files: "To avoid conflict ATM - to be removed later"

Hello Everyone - is there a FreeBSD strategy ? I am interested in making easy to have FreeBSD as daily driver - that will include classic apps, but also local OpenSource AI, virtualization (similar to Virt-Manager) on a desktop that is as much possible BSD/MIT licensed - so far I see only two that meet this criteria - Lumina and Enlightenment - I have used them both - but it seem that FreeBSD lacks a coherent strategy to get new

generation of programmers, also make it suitable for businesses (other than Sony, Netflix and Apple)...

wdym a strategy? or "make it suitable for businesses"

FreeBSD just offers an operating system, you can use it, contribute it, fork it whatever

but there's no grand scheme for gaining new contributors

acu: how about using virt-manager if you want to use virt-manager?

levitating: yes - it is obvious - I assume the average contributor for freebsd is 55... which is amazing, seasoned and dedicated people... but not having a strategy beyond core code ? That grand scheme needs a vision, I agree, that was my question... if someone can point me to strategic plan for freebsd

I am not sure I could point you to any "strategic plan" for any FOSS project

interesting... I would need to look at two immensely succesful projects nextcloud and huggingface... but there are others...but is a good point - I know Debian was totally irrelevant until Ubuntu came about... it is so pity that FreeBSD lost traction - PC-BSD freenas Trueos were some good solid attempts - but they died... that is why I am asking where is the mission and strategy of FreeBSD who is responsible to generate it... I am

sure there is a team... that is why I was asking here...

nextcloud and hugginface don't see nearly as much contributions as FreeBSD, you can't compare a cloud service with an entire operating system...

debian wasn't irrelevant before Ubuntu, not nearly

and FreeBSD never had traction

hm, seems like freebsdfoundation.org/blog/technology-roadmap didn't get updated for some years now

the website is broken for me, doesn't let me donate

nimaje: thanks, yeah that seem a cool starting point... I will contact few people from there, I am pretty sure they know more than most...

please don't bother the foundation people

levitating: what's broken?

you can donate with paypal

no the header menu above is stuck and covering the button

I do it evry year without problems

works for me

oh.. now I can even use credit card instead of paypal, that's even better

I am trying to see if I can have generative ai large language models running on freebsd (both doing inference on CPU or GPU) - I have some servers I can use temporary (including GPU).. but I have no time (so I can ask perhaps FreeBSd foundation to fund some Ai Master students - for some work that would just make FreeBSD as usable as FreeBSD in AI - both as local install or server based...

It is so difficult... no University is using FreeBSD on their Unix classes... 99% of computer students of hackers do not know FreeBSD exists and has amazing license and underlying engineering

acu: that's sad story, what univestity is that ?

I hired few people, and delivered FreeBSD based solutions... but it was not sustainable - we needed to spend 10% more time in early phases to deploy anything, and 10% more time to maintain and update them (compare to Debian or Ubuntu - or Redhat)... so I was forced to go back to linux...

mzar: do you know any University or College that uses FreeBSD in their Unix courses ?

yes, if the cost of labour has to be considered, FreeBSD is not the cheapest solution

acu: sure

acu: cl.cam.ac.uk/teaching/2223/AOS

hell my cs bachelor barely touched unix

and when it did it was on an RPi

Really they should let you perform your assignments in sdf.org :)

levitating: you mean like stevens.netmeister.org/631 ;)

darmstadt where bcr works

sdf.org is suggested if you cant get your own install working

getz that's very cool

hrm, so my new USB DAC sounds great, bitperfect works, but i'm seeing mpd on song change that the start of the song has a partial second clipped off

wonder if there's a buffer or something needs to be expanded

the best is the students to run FreeBSD desktop as daily driver as they do with Ubuntu... than you become intimately familliar and confortable .... but there is also the JOB aspect - if you do any search on Indeed, Monster, Dice or alike and put FreeBSD it gives you 0 hits... so if there is no job...it makes it a bit difficult... its catch 22 - but that is why I am asking who is responsible for FreeBSD strategy beyond code

can't even really expect students to evne use ubuntu

acu: debian irrelevant until ubuntu? what?

I study at a decent university but few of our CS students use linux

i think the issue for both of those is: desktop

strategy

what?

debian blazed a trail and set standards across the linux world for ages before ubuntu came along

ubuntu made a spit and shiny desktop on modded debian

and yep, the desktop monopoly of windows products is a problem. we are literally crippling the next generation of programmers and admins

am back

laptop did a weird lil reboot

what was that about desktop?

my laptop was last up 180 days :P

you have 180 day uptime?

stable machine

dude, i work on servers with years of uptime.

this laptop does weird stuff fromt time to time

those servers have to be patched while running, no downtime is ok

this uptime is irrelevant nowadays - any OS can stay on years...

I can believe that, but servers are made to be stable

I have donate a few bucks to FreeBSD Foundation, thanks for the reminder levitating

*donated

mzar you're welcome, and thank you for supporting one of my fav os's :)

I know, FreeBSD is like a woman you love all, but you marry someone else for convenience :)

I hate that

Demosthenex So is it running an old kernel by now or is there some way to patch/hotswap the kernel?

levitating: aix has fewer kernel CVE's, and IBM has made a new feature to allow you to live migrate running applications across hosts, basically moving processes and memory to a box where the updates live

this is not freebsd.

but I have no choice - I run 2 years almost 100% FreeBSD - desktop and servers (of course with few exceptions) but it was not sustainable, people started a "mutiny" against me forcing them to use FreeBSD

acu: why would what you use matter to them?

freebsd is the best free open source unix.

AIX is the best commercial unix.

i do both.

Cognitive overload... a lot of more work, and lack of future perspective... if they need to do Redhat or Ubuntu or Suse - so they can pay rent and tuition for their kids...

Everybody runs from AIX...even IBM Z servers are slowly switching to Linux

there are no experts

you need to know details

We needed someone to train others for IBM Z14 and Z15 - and few months later, we are still looking :)

is there a fairly well performaing way to have an encrypted folder / file system on SSHFS?

I'm renting a hetzner storage box, i'm using that as a storage extension to a hetzner VPS

but ideally I'd want the data to be encrypted at rest there

*well performing

the vps runs freebsd 14.1

Does anyone know if bhyve in FreeBSD 14.x (which runs as root of course) uses Capsicum to lock down the VMs it is running to help prevent escaping by default?

Ah nevermind, I was able to find my answer via a phrack issue: phrack.org/issues/70/11.html#article

acu: pfft. workloads that can run on windoze are moving to linux. small loads. IBM's still the backbone of every largest anything :P

I guess an interesting question I have is: Is there a sane and easy way to tell if a specific running process is making use of Capsicum?

linux is just the new windows, i can't even trust it to small workloads like i can freebsd.

and desktop computing platform != data center computing platform

commodity OS and HW don't belong in data centers, or you get the full windoze experience. ransomware, crowdstrike cascading outages. professional IT should expect more.

and yes, i just called every purchasing manager and developer pushing windows servers in production an idiot.

i have for 30 years, and only been proven right over time

Cyrus: ps has a capability mode bit for the state field

kevans: Ah nice, so it does. 'C'. Thank you.

what is the doas equivalent to `sudoedit`/`sudo -e`?

doas editorgoeshere?

but that runs the editor as root

i see

i was hoping doas had something similar to sudoedit where it creates a temporary file for you to work on :/

and how would that abort if the editor returns some non-zero exit code?

i had been using doas $EDITOR, but coming from a system with sudo, it felt odd

i'm guessing the temp file wouldn't be written

If you want the features of sudo then you must use sudo.

that is true

I found two shell scripts that try to be a sudoedit replacement using doas (but both don't abort on non-zero exit code of the editor, not sure what else they do diffrently to sudoedit), not sure how well they keep the rights on the files

i guess it wouldn't hurt to try making a shell script for this myself :)

There's doasedit.

i just found it too :O

oh, but that seems to lose original file permissions

yeah i'm a bit disappointed that doas doesn't do that by itself

although...

emacs + tramp + |doas::

i've never seen anyone actually follow the directions that iirc are written right in the sudo manpage to mitigate the risk of unlogged sudo activity via shell escapes

i did once, and i had to write a cheatsheet for my fellow admins, teaching them how to use sudoedit

... and sudo find, and sudo tee, because you can't sudo cd or > sudo.

actually -- github.com/jaredjennings/puppet-cmi…-sudo/blob/master/sudo-boldface.tex

I'm using "doas" it's a openbsd replacement to avoid sudo

i'm in favor of using less code to do mostly the same thing

and i can appreciate that many openbsd users may not be subject to the same kind of audit requirements that caused sudo to grow so much

nimaje: another bug to file ;)

doas not implementing this probably has to do with minimalism as you've inferred, however, an offical implementation would probably be better than the shell scripts we've seen hacked together.

i am concerned, with reimplementations in general, that there may be wisdom lost. some of the constraints under which the original was made don't exist anymore, and don't need to be catered for. the original has hacks that paper over problems faced at layers of abstraction above or below it, and maybe those layers have real fixes now.

but some of the warts probably belong there, and an attempt to make a new smooth thing is doomed to relearn a painful old lesson

hm, does doas has some "caching" to avoid making you type the password over and over if you run a series of commands with evelated priveleges? the scripts I saw had nothing to deactivate something like that for the editor, so if doas has something like that a shell escape could run doas <cmd> to run <cmd> without a password from the unpreviliged editor

(no idea if sudoedit does something against that)

whaaaat

> doas - dedicated openbsd application subexecutor

that is totally a backronym

I'll just note that sudoedit runs the editor UNprivileged to avoid editor escape vulnerabilities.

sudo's overblown. just use ssh keys locked to localhost and specific commands.

good point Demosthenex

oh yeah, that doesn't need root privs to allow users to establish cross user jobs.

where sudo only root can edit sudoers

nimaje, cvsweb.openbsd.org/cgi-bin/cvsweb/s…9&content-type=text/x-cvsweb-markup

in the authuser function, the persist flag is dealt with

it ... sets a VERAUTH ioctl on the tty for 5 minutes (hardcoded)?

hum, man.openbsd.org/tty.4#TIOCSETVERAUTH

There are really two basic modes people use. su/sudo/doas/ssh mode getting a full root shell with full access. sudo/doas mode with restricted privilege access. Using ssh for the first is easy but the latter is tedious. For the latter it's really easier to use sudo/doas than ssh by a lot.

And, third, "sudo su -"

That's just another way for the former case of full shell access.

yes, it's true. i just wanted to kvetch about it.

yeah, we don't have the tty-associated auth bits

also i was thinking about the meme with the three dragons who are supposed to be menacing, but the third is super derpy

that'd be cool, but I can't help but feel there's a better abstraction somewhere that could be more generally useful

^

github.com/nholstein/OpenDoas appears not to have persist at all?

probably not, I don't think they support persist if you can't do it 'securely'

... oo, that is not the one that is in freshports

I think in my ideal world, we support something like Linux's keyrings and have one that can be attached to the tty as well as the session and user

and from the man page, "Works on OpenBSD only, persist is not available on Linux or FreeBSD."

so you can do things like this or random key blobs for... other purposes

I also respect that sudo has reacted to many years of people using it and complaining about edge cases and solving them. I know people complain about the extra code of those solutions but that's only because the edge case did not affect them personally yet. As soon as it does they will want that mitigation included in their favored minimal utility tool too.

yes, that, exactly.

some people will not ever want ldap support or terminal recording. but maybe there are things that sudo refuses to do, and spends lines of code checking for and preventing, that any clean reimplementation will have forgotten

honestly i've read more about doas in the past half hour than in the past six months

Is there a newer gpu-firmware-kmod with the firmware files supported by drm-61-kmod?

I got a framework 16 and was hoping the gpu (navi 33) would work

i've installed it here and there, and it has done what it said on the tin, but i didn't look into any more detail than that

Here is an example I ran into some time back. "su -" does not leave the user with a /dev/tty owned by root. This caused me problems. I don't remember the details now. But something was unhappy and did not work correctly that way. "sudo -i" allocates a new pty with expected permissions. It avoids the pitfall.

"doas bash" has the same problem as "su -" has. It does not have the mitigation for the problem.

rwp: su/sudo/doas/ssh for full access, sudo/doas/ssh for restricted.

rwp: these sudo changes came after doas became a thing, no? I believe that healthy competition pushed listening to sudo users feedback in some way, too. I know a few Linux users who replaced sudo with doas.

Demosthenex, Using ssh for restricted access is tedious. Possible yes. But much more tedious than with either sudo or doas.

regis, I don't really know the timeline of doas development. But sudo has been around since what feels like forever.

I also feel that a lot of people's complaints about sudo being bloated is that sudo uses PAM which enables all of the users who use OATH and tokens and other access methods. That's called bloat by people who don't use those access methods.

rwp: "The doas command first appeared in OpenBSD 5.8" (Released Oct 18, 2015). I however don't know when this reaction to sudo users complaints you're mentioning took place :)

I live in Colorado and CU Boulder is not that far away. Therefore when CU Boulder was making sudo enhancements in the mid 1990s the culture was to use it. I first used sudo on HP-UX while working for HP in those years.

flak.tedunangst.com/post/doas - 20 Jul 2015 - "There were some concerns that sudo was too big, running too much code in a privileged process"

On the surface therefore it seems that sudo was developed into a very similar form to what it is today about 20 years before doas.

sudo.ws/about/history - CU-Boulder implementation ~1986

That's not a bad thing for doas. Having a good working example to learn from first and then make a rewrite can be very helpful. I use tmux for example and it benefited from having screen already in heavy use for years.

With sudo having been developed on BSD systems I have never understood people thinking that it was a linux tool.

rwp: its 2 lines of script. it also works on systems without sudo

No data to back up this statement but I think thad doas gained a lot of users after sudo's CVE-2021-3156. And it wasn't a tool coming from some noname GitHub account, but from trustworthy OpenBSD team, so it secured adoption in corporate environments, not just on private workstations.

good point regis

regis: i agree completely. doas came about because sudo is too big. complex things are hard to secure.

i just suggest SSH because... you use it anyway

ssh is proven to work solution, the same is su(1)

so how can i prevent my USB audio from clipping the start of songs.

Demosthenex, For ssh I assumed we were talking about either command="command" in the authorized_keys file or ForceCommand configuration. No?

rwp: from="127.0.0.1",command="" ssh-rsa .........

Working with ssh's authorized_keys file command= works and so does ForceCommand but I think limiting to something more than backup only is very tedious. I wrote a helper utility for me.

Demosthenex, So... How do you use it to limit access to something like rsync for backup only? What you showed only limits access from the localhost.

always always lock the host from ip if it's an unencrypted key disk

rwp: from="backupserver",command="rsync ..." ssh-rsa .........

s/disk/on disk/

So that's one command. Add twenty more commands that are all needed acquired over time and that's where I say trying to make that mechanism work is very tedious. Better to use something more like sudo or doas in that case.

Certainly using ssh for a full root shell access is no problem. That's the first case I categorized above.

rwp: itemizing commands is the nature of security, not the fault of ssh

It's the latter case of trying to limit access where I think using ssh's command= access is tedious. I wrote a helper utility to address this for the case I needed. Basically bolting on an external solution to it.

rbash

I wasn't faulting ssh for it.

i'd trust a restricted shell over an extra wrapper

It is very difficult to set up a restricted shell in a secure way. Many people have tried. And when I find myself in one I can usually cut them one and escape in seconds.

if you have their path set to the only binaries they can run, and restrict (no user env), its better

my argument is that i don't trust myself to have a hole in my shell script, vs the many experts working on restricted shell

I have escaped from many a restricted shell when people have tried to limit me using one. Just saying... They are hard to get right.

they are. don't give people interpreters ;]

Of course that was back at $JOB and the people setting them up were not necessarily experienced doing so.

i still escape on ibm hmc's often

Having exhausted the topic of using ssh for limiting actions let's return to complaining about su/sudo/doas instead. :-)

Are there versions of vi and ed that lock "!"?

I recall there being a restricted mode for vi.

rwp: i'm not saying you're wrong ;] please continue

I am probably remembering a restricted vi incorrectly. Or maybe it was a local hack by someone. But definitely if vi is allowed then it's an escape path.

Sidebar: I see that ee is in FreeBSD base. ee was written by Hugh Mahon. I used to work near-ish Hugh. He worked in the next building over.

Demosthenex, I think people often configure ssh incoming limited by authorized_keys command= and from= and such to limit backup and for other limited things. It's pretty easy to set up one thing for one user.

rwp: i do it all the time for complicated backups.

in particular, i have keys which trigger db freeze/thaw, mount/unmount, and flashcopies

And I think people often use ssh to jump to a full root shell. That's a good use. And emacs tramp has ssh for a root level access it can use from the selection of protocols too.

Demosthenex, So it sounds like you have a map of multiple keys with different keys doing different access? Is that what I might gleam from that comment?

yes, different users, different hardcoded commands

That's certainly going to be okay from a security perspective. No complaints.

the rule is simple: a more production/priv system/user may have open remote control of a nonprod/nonpriv user.

but a nonprod/nonpriv can only have locked commands into prod

Ah, there's a restricted ed, but no restricted vi that I can see.

Ah... red, of course. How could we have forgotten? :-)

regis, Regarding your comment "it wasn't a tool coming from some noname GitHub account" ... "from trustworthy OpenBSD team". But OpenBSD is the home of sudo too. sudo is not coming from a noname either. It's coming from a very reputable source.

Also though OpenBSD says they are the secure system they have had their own big problems at times too. They created their own SMTP daemon and then it had a remote code execution flaw in it that was just as large as any from anywhere. (I forget the detail now. I'll search for it.)

How could such a huge vulnerability hole have come from such a reputable source such as OpenBSD? (Read with sarcasm.) Because anyone and any group can make a mistake. What matters is how they react to the mistake.

because they didn't write it in rust

i'm certain that's not the reason

In case people haven't been following the mailing list discussion in real time I will leave this LWN summary of it here. FreeBSD considers Rust in the base system: lwn.net/SubscriberLink/985210/f3c3beb9ef9c550e

sudo is not from openbsd, just the maintainer is also on the openbsd project

rwp, pishposh, it's been "a heck of a long time" since then ;)

Hmm... It's a fine line. Miller is an OpenBSD developer. The home of sudo is on OpenBSD and it is ported to other systems. Leaving the question as to whether OpenBSD considers sudo part of OpenBSD or not I do not know.

er, wait, is smtpd "in the default install"... hm

considering they use 'doas' now i would be surprised if they consider it part of the project

OpenSMTPD is definitely part of OpenBSD. I clearly remember Theo de Raadt talking about it as being part of OpenBSD.

i am quoting the slogan seen on openbsd.com for humorous effect, "Only two remote holes in the default install for a heck of a long time" iirc

jaredj: for extremely large values of two

I booted up my OpenBSD 6.8 system and it has /usr/sbin/smtpd /usr/bin/doas but /usr/local/bin/sudo

oho hohoho oops!

jaredj: iirc 'in the default install' only includes things that are turned on by default, so the surface area is much lower than 'is it included'

"Only two remote holes in the default install, **in** a heck of a long time"

having two remote holes "**for** a heck of a long time" was a misquotation. i regret the error, etc

kevans: yeyeah, sure, that's what gave me doubts that my initial quote applied

'for' is funnier to think about

:D

oo so here's a question. what does "overlay mount" properly mean in the context of ZFS?

in the zfsprops man page it seems to be about whether you can mount something somewhere even if that somewhere is in use

basically whether zfs will allow you to shadow another mount

it's not an overlayfs type overlay, the lower contents are just hidden and zfs mounted on top

i expected it to mean that if i have filesystem a mounted on /x, a has overlay=on, and i mount b on /x, i see a's files, and b's files

(afaict)

it does not, apparently, do that

and also of course i want a to be read-only, and all the writes to go to b

so if overlay=off, b will be prevented from being mounted on /x when a is already mounted there

and if overlay=on, the mount will be allowed, but b will shadow a

right, you want something more like unionfs(4)

maybe that is how they do it. i thought somebody was making container images ... OCI, is it? ... available using ZFS means

AllanJude has talked about wanting to do a zfs-native overlayfs type thing, but I don't think that's been made a reality yet

mmm. maybe that's it

vanlug.ca/2024/05/05/oci-containers-for-freebsd mm i think this was the latest i saw about it, and i forgot whatever it said. rewatching the talk

hi there. i had opensmtpd running on 13.2, but when i upgraded to 13.3 (including packages), it's stopped working. i'm pretty sure because /etc/mail/mailer.conf now references sendmail. uninstalling and reinstalling the opensmtpd package does not fix mailer.conf, though the install script in the package purports to do so. the handbook says take up ports issues with the maintainer; are ports and

packages sufficiently synonymous that i should bring this up with the port maintainer? (i couldn't find any guidance in the handbook on what to do about problems with packages)

Hello all

thorongil: yes, everything package does is defined in the port, so if package scripts misbehave you can contact port maintainer

yuripv: thanks!

thorongil: though I thinking using bugzilla (with a proper problem description) would be better than contacting maintainer directly

I think, too

In a service script, how can I force a process to run in the background - specifically a server on a port? Thanks

I've tried /usr/sbin/daemon /usr/local/bin/python3 /opt/uredis/uredis-server.pyz --daemon

but it doesn't work :/

doesn't work how?

yuripv: understood

pastebin.com/M9AN5GMz - It will print the message but not actually start the server

thorongil, Does "pkg info -D opensmtpd" say that you need to install a /usr/local/etc/mail/mailer.conf file with the opensmtpd configuration? The postfix package does for when installing postfix.

samjiman, please use dpaste.org just to cut down the spam

thorongil, paste.debian.net/plain/1327363 is what the postfix package description instructions say.

@daemon: Okay: dpaste.org/BEZwi

;)

And here is my /usr/local/etc/mail/mailer.conf file customized for postfix, which is probably identical for opensmtpd too. paste.debian.net/plain/1327364

samjiman, if you run that command from the console does it work?

with service uredis onestart it works, but it won't put the process into the background - I have to kill it

which isn't what I want

Do I maybe need it to run after user log in?

I don't understand why you need the daemon(8) if it seems to have the --daemon option?

or may be don't specify the option?

The --daemon flag is just to make it daemon safe - it isn't actually a daemon

oh ok, sorry

I've got it working with systemd

No need to apologize, that is ambigious

/usr/sbin/daemon should make it background

I wonder if its something to with how Python runs ports

I'm not sure

I should maybe look at the service file for nginx

mhmm its more likely the python script is hooking stin

stdin

Ah it is :)

Thanks

Can I just redirect stdin then?

to like /dev/null?

Wait, I mean i'm writing to stdout

Not stdin

Got it to work: /usr/sbin/daemon -P /var/run/${name}.pid /usr/local/bin/python3 /opt/uredis/uredis-server.pyz --daemon > /dev/null

Thanks for the help

kevans, wohohoho, github.com/oci-playground/freebsd-podman-testing

> and also come and find us on the OCI Slack

bah! humbug.

rwp: sorry, was afk. no, the package message for opensmtpd does not mention tweaking /etc/mail/mailer.conf. and the install script (seen in pkg info -R opensmtpd) clearly contains code that is intended to fix mailer.conf.