Re: Preferred TERM for pkg_add
On Mon, Jan 09, 2023 at 01:52:03PM +, Nicholas Marriott wrote: > > From a quick look it will happily fall back to carriage return and space > if the capabilities it would prefer (el and hpa/RI) are not present, so > probably anything would do. > > Or you could check if the terminfo entry existed with something like > "tput el >/dev/null 2>&1" before running pkg_add. > Thanks for taking a look and suggesting how to detect available terminfo entries. To keep things simple it seems we can start with a static value. We can always make it more dynamic later if needed. As for dumb vs unknown it seems dumb has one less capability: ``` $ infocmp dumb # Reconstructed via infocmp from file: /usr/share/terminfo/d/dumb dumb|80-column dumb tty, am, cols#80, bel=^G, cr=^M, cud1=^J, ind=^J, $ infocmp unknown # Reconstructed via infocmp from file: /usr/share/terminfo/u/unknown unknown|unknown terminal type, am, gn, cols#80, bel=^G, cr=^M, cud1=^J, ind=^J, ``` They are identical except for unknown also having the "gn" capability (generic line type as defined in terminfo(5)). So just going with the "least capable" dumb seems like a good start. Regards, Patrik Lundin
Preferred TERM for pkg_add
Hello, There was recently a bug report opened for the ansible module openbsd_pkg, where someone was getting errors due to pkg_add disliking their TERM setting: https://github.com/ansible-collections/community.general/issues/5738 Basically they are running TERM=xterm-kitty locally, which makes pkg_add disable the progress meter, easily testable like so: ``` orbb# nmap ksh: nmap: not found orbb# TERM=xterm-kitty pkg_add nmap No progress meter: failed termcap lookup on xterm-kitty quirks-6.42 signed on 2022-12-09T12:59:38Z orbb# nmap Nmap 7.91 ( https://nmap.org ) [...] ``` I can agree with the reporter that it would be better to have the ansible module "do the right thing" and set some lowest common denominator TERM instead of depending on the whims of a local environment. From what I can tell both "dumb" (as suggested by the reporter) and "unknown" seems to still print the progress bar: ``` # TERM=unknown pkg_delete nmap nmap-7.91p2: ok Read shared items: ok ``` ... and: ``` # TERM=dumb pkg_add nmap quirks-6.42 signed on 2022-12-09T12:59:38Z nmap-7.91p2: ok ``` Basically I am asking if any specific choice of a TERM would be preferred if we would make openbsd_pkg always set one of them for the different pkg_* tools. Regards, Patrik Lundin
Re: Question regarding (portable) OpenNTPD adjfreq
Ugh, sorry about the garbled layout of the previous message. I should not attempt to do these write ups on the road away from mutt :(. -- Patrik Lundin
Question regarding (portable) OpenNTPD adjfreq
t;Mar 8 10:11:22 ntpd[52192]: adjusting local clock
by -8.627604s", 68, MSG_NOSIGNAL, NULL, 0) = 68
52192 adjtimex({modes=ADJ_OFFSET|0x8000, offset=-8486065, freq=1875275,
maxerror=1600, esterror=1600, status=STA_UNSYNC, constant=2,
precision=1, tolerance=32768000, time={1488964282, 620376}, tick=10006,
ppsfreq=0, jitter=0, shift=0, stabil=0, jitcnt=0, calcnt=0, errcnt=0,
stbcnt=0}) = 5 (TIME_ERROR)
52192 poll([{fd=5, events=POLLIN|POLLOUT}], 1, 4294967295) = 1 ([{fd=5,
revents=POLLOUT}])
52192 writev(5, [{"\1\0\0\0\0\0\0\0\0\0\0\0\24\0\0\0\0\0\0\0",
20}], 1) = 20
52192 poll([{fd=5, events=POLLIN}], 1, 4294967295
===
I initially asked bcook@ about this since it was spotted on -portable
and he suggested I bring it up here.
--
Patrik Lundin
Re: new feature in pkg_add(1)
On Thu, Jun 23, 2016 at 06:44:19AM +0200, Patrik Lundin wrote: > > I will play around with this and see what I can come up with, thanks! > For any interested parties there is now support for the pkg_add branch-syntax in the openbsd_pkg package management module in ansible upstream: https://github.com/ansible/ansible-modules-extras/blob/devel/packaging/os/openbsd_pkg.py Using the "pkg_info -Iq inst:" syntax was actually a lot easier to work with than -e, so that helped me remove some additional cruft from the module as well. Thanks to espie@ for pointing out that way of using the tool. -- Patrik Lundin
autoinstall: Support DHCP option bootfile-name
Hello,
Trying to set up autoinstall with net/kea as the DHCP server ended up
problematic. The issue is that it considers the "file" field in the DHCP
header deprecated in favor of the "bootfile-name" DHCP option. There is
therefore no way to configure the equivalent of the ISC dhcpd "filename"
setting.
The problem then is two-fold: First of all dhclient does not request
this option by default, and secondly, the installer does not check for
the setting.
Making dhclient request the option was easy enough (diff below). My idea
is then to have install.sub check for "filename" first, and then look
for "option bootfile-name" if no match was found.
The following regex based on current install.sub matching seemed to work
at least.
===
sed -E '/^ *option bootfile-name "(.*\/)?auto_(install|upgrade)";$/!d;s//\2/;q'
/var/db/dhclient.leases.em0
===
What do people think about this?
I did ask about the lack of ability to configure the "file" field on the
kea-users list as well, thread can be read here:
https://lists.isc.org/pipermail/kea-users/2016-July/000435.html
--
Patrik Lundin
Index: clparse.c
===
RCS file: /cvs/src/sbin/dhclient/clparse.c,v
retrieving revision 1.95
diff -u -p -u -r1.95 clparse.c
--- clparse.c 3 Jun 2016 02:31:17 - 1.95
+++ clparse.c 10 Jul 2016 18:42:14 -
@@ -110,6 +110,8 @@ read_client_conf(void)
[config->requested_option_count++] = DHO_DOMAIN_NAME_SERVERS;
config->requested_options
[config->requested_option_count++] = DHO_HOST_NAME;
+ config->requested_options
+ [config->requested_option_count++] = DHO_BOOTFILE_NAME;
if ((cfile = fopen(path_dhclient_conf, "r")) != NULL) {
do {
Re: new feature in pkg_add(1)
On Wed, Jun 22, 2016 at 02:19:26PM +0200, Marc Espie wrote: > On Tue, Jun 21, 2016 at 10:43:07PM +0200, Patrik Lundin wrote: > > The reason for doing this is that it is much faster than just blindly > > trying to install a package, and does not hammer mirrors needlessly. > > > > Are there any plans to teach pkg_info -e about "%"? Is it even possible? > > Okay, just committed the exit code fix. > > pkg_info -Iq inst:python%3.5 > will perform just as you would expect. Awesome :). I will play around with this and see what I can come up with, thanks! -- Patrik Lundin
Re: new feature in pkg_add(1)
On Fri, Jun 17, 2016 at 04:02:36PM +0200, Marc Espie wrote: > I was waiting for snapshots to come up with the new stuff, but it > looks like amd64 will be a bit late. Someone is still hiking in > the mountains... > > > A week ago or so, I committed support for some disambiguating > filter in pkg_add. > > This means that you can now simply install packages for ports which > have several versions in the tree without having to know the exact > version. > > For instance, > > pkg_add python%2.7 > will install a python from the lang/python/2.7 branch. > I am the maintainer of the OpenBSD package handling module in ansible and have for a long time had a request to support more relaxed package names. Until now the suggested solution has been to use the pkg_add -z invocation. My main problem with using pkg_add -z has been that the package names it allows can not be used with "pkg_info -e" or "pkg_delete". I notice that pkg_delete does understand "%" which is very nice: === # pkg_delete python%2.7 python-2.7.11p1: ok [...] === However, "pkg_info -e" does not understand it: === # pkg_info -e python%2.7 Invalid spec: python%2.7 === I use pkg_info -e to check if a requested package is installed or not prior to attempting to install/remove it. The reason for doing this is that it is much faster than just blindly trying to install a package, and does not hammer mirrors needlessly. Are there any plans to teach pkg_info -e about "%"? Is it even possible? The full ansible upstream discussion can be found here if anyone is interested: https://github.com/ansible/ansible-modules-extras/issues/97 Anyway, thanks for working on this, and thanks to landry@ for mentioning this was in the works :). -- Patrik Lundin
pkg_info(1): fix return value description for -e
Hello, The '-e' option to pkg_info is currently described in the following way: === If the package identified by pkg-name is not currently installed, return 0, otherwise return 1. === However, it behaves the other way around: === $ pkg_info -e 'vim-*-no_x11' inst:vim-7.4.900-no_x11 $ echo $? 0 $ pkg_info -e 'vim-*-no_x12' $ echo $? 1 === Diff to man page below (removing a negation always feels good). -- Patrik Lundin Index: pkg_info.1 === RCS file: /cvs/src/usr.sbin/pkg_add/pkg_info.1,v retrieving revision 1.51 diff -u -p -u -r1.51 pkg_info.1 --- pkg_info.1 7 Oct 2015 17:52:38 - 1.51 +++ pkg_info.1 27 Feb 2016 16:41:45 - @@ -87,7 +87,7 @@ allows you to test for the presence of a prerequisite) package from a script. If the package identified by .Ar pkg-name -is not currently installed, return 0, otherwise return 1. +is currently installed, return 0, otherwise return 1. In addition, the names of any package(s) found installed are printed to stdout unless turned off using the .Fl q
Re: uftdi: Attach Telldus TellStick Duo
On Mon, Dec 21, 2015 at 05:40:14PM +0100, Patrik Lundin wrote: > > This was pretty discouraging: it appears the supported program works > better when the kernel knows less about the device. It uses libftdi, > which I guess is supposed to contact the generic device directly. > > Any input on how this should be managed? Currently I feel stuck between > a rock and a hard place :). > Just to be clear: If I am not missing something obvious I ask that you disregard my patch. The telldus-core package is what is supported by upstream, the rfcmd tool is deprecated (I used it as a PoC because there was less moving parts involved). Sorry for the noise, sigh. -- Patrik Lundin
Re: uftdi: Attach Telldus TellStick Duo
On Mon, Dec 21, 2015 at 02:12:41PM +0100, Patrik Lundin wrote: > > Currently it is only attached as an ugen device: > === > ugen0 at uhub1 port 2 "Telldus TellStick Duo" rev 2.00/6.00 addr 2 > === > > The diff below makes it attach as an uftdi device: > === > uftdi0 at uhub2 port 1 configuration 1 interface 0 "Telldus TellStick Duo" > rev 2.00/6.00 addr 2 > ucom0 at uftdi0 portno 1 > === > Hmm, so this was interesting... After getting the rfcmd tool to work I moved forward with using the replacement telldus-core software instead, which has a deamon called telldusd. After struggling for a while trying to get telldusd to work I rolled back to the previous kernel, and suddenly telldusd started working. I can see that it has opened a bunch of ugen devices: === # fstat -p 17591 USER CMD PID FD MOUNTINUM MODE R/WSZ|DV root telldusd 17591 text /usr/local 1013387 -r-xr-xr-x r 440042 root telldusd 17591 wd / 2 drwxr-xr-x r 512 root telldusd 175910* unix stream 0x802ec180 root telldusd 175911 pipe 0xff011fd2be10 state: root telldusd 175912 pipe 0xff011fd2be10 state: root telldusd 175913 / 865 crw-rw rw ugen0.00 root telldusd 175914 pipe 0xff011fd2b9d8 state: root telldusd 175915 pipe 0xff011fd2b9d8 state: root telldusd 175916* unix stream 0x802b9d80 root telldusd 175917 / 867 crw-rw w ugen0.02 root telldusd 175918 / 866 crw-rw r ugen0.01 root telldusd 175919* unix stream 0x80355880 === This was pretty discouraging: it appears the supported program works better when the kernel knows less about the device. It uses libftdi, which I guess is supposed to contact the generic device directly. Any input on how this should be managed? Currently I feel stuck between a rock and a hard place :). -- Patrik Lundin
uftdi: Attach Telldus TellStick Duo
Hello,
I recently aquired a Telldus Tellstick Duo
(http://www.telldus.se/products/tellstick_duo). It differs from the
classic Tellstick in that it is both a transmitter and a receiver.
The hardware:
===
# usbdevs -v
[...]
port 1 addr 2: full speed, power 90 mA, config 1, TellStick Duo(0x0c31),
Telldus(0x1781), rev 6.00, iSerialNumber A703AJR6
[...]
===
Currently it is only attached as an ugen device:
===
ugen0 at uhub1 port 2 "Telldus TellStick Duo" rev 2.00/6.00 addr 2
===
The diff below makes it attach as an uftdi device:
===
uftdi0 at uhub2 port 1 configuration 1 interface 0 "Telldus TellStick Duo" rev
2.00/6.00 addr 2
ucom0 at uftdi0 portno 1
===
I have verified that I can use it with rfcmd
(https://github.com/telldus/telldus/tree/master/rfcmd) to place a wall
plug in the on and off state with the following commands (this requires
a patch to rfcmd.c which makes it use 9600 baud instead of 4800):
===
./rfcmd /dev/cuaU0 NEXA A 1 1
./rfcmd /dev/cuaU0 NEXA A 1 0
===
While not strictly related to this diff, maby the line "MetaGeek tagged
products" should be replaced with "Mecanique tagged products" in usbdevs?
--
Patrik Lundin
Index: usbdevs
===
RCS file: /cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.654
diff -u -p -u -r1.654 usbdevs
--- usbdevs 15 Jul 2015 13:25:49 - 1.654
+++ usbdevs 21 Dec 2015 11:14:48 -
@@ -2918,6 +2918,7 @@ product MELCO WLIUCGNM2 0x01ee WLI-UC-G
/* MetaGeek tagged products */
product MECANIQUE WISPY0x083e MetaGeek Wi-Spy
product MECANIQUE TELLSTICK0x0c30 Telldus Tellstick
+product MECANIQUE TELLSTICK_DUO0x0c31 Telldus Tellstick Duo
/* MetaGeek products */
product METAGEEK WISPY24I 0x2400 Wi-Spy 2.4i
Index: uftdi.c
===
RCS file: /cvs/src/sys/dev/usb/uftdi.c,v
retrieving revision 1.74
diff -u -p -u -r1.74 uftdi.c
--- uftdi.c 18 Jun 2015 09:47:16 - 1.74
+++ uftdi.c 21 Dec 2015 11:14:48 -
@@ -634,6 +634,7 @@ static const struct usb_devno uftdi_devs
{ USB_VENDOR_MATRIXORB, USB_PRODUCT_MATRIXORB_LCD_01FE },
{ USB_VENDOR_MATRIXORB, USB_PRODUCT_MATRIXORB_LCD_01FF },
{ USB_VENDOR_MECANIQUE, USB_PRODUCT_MECANIQUE_TELLSTICK },
+ { USB_VENDOR_MECANIQUE, USB_PRODUCT_MECANIQUE_TELLSTICK_DUO },
{ USB_VENDOR_MELCO, USB_PRODUCT_MELCO_PCOPRS1 },
{ USB_VENDOR_MOBILITY, USB_PRODUCT_MOBILITY_ED200H },
{ USB_VENDOR_OCT, USB_PRODUCT_OCT_US2308 },
Re: crypto softraid and keydisk on same harddrive
On Sat, Apr 25, 2015 at 10:54:22PM +1000, Joel Sing wrote: > > Apologies for not getting back to look at this - the above diff is in part a > hack and it needs to be more cleanly implemented before it is committed. > Additionally, it needs to be implemented and tested for all platforms that > support softraid boot. I'll attempt to get this done over the next couple of > weeks. > Any progress on this? I would be happy to help you test diffs. -- Patrik Lundin
Re: crypto softraid and keydisk on same harddrive
On Sat, Apr 25, 2015 at 10:54:22PM +1000, Joel Sing wrote: > > Apologies for not getting back to look at this - the above diff is in part a > hack and it needs to be more cleanly implemented before it is committed. > Additionally, it needs to be implemented and tested for all platforms that > support softraid boot. I'll attempt to get this done over the next couple of > weeks. > No worries, I see you are hacking on a bunch of stuff in other parts of the tree, so I was just trying to ease your burden by possibly soliciting help from other devs. > In the meantime, as previously mentioned, the more effective way of clearing > a > softraid crypto volume is to recreate the volume with 'bioctl -C force' (or > even just dd over the first 1MB of the RAID partition) - that nukes the keys > that were used to encrypt the data, making the key disk or passphrase > completely useless. > When you say "dd over the first 1MB of the RAID partition", does that mean the RAID partition containing the keydisk, or the RAID partition storing the actual encrypted files? The recipe I put together for preparing the encrypted drive looks like this (executed by a custom built installer): === echo "Creating MBR partition on physical disk" fdisk -iy sd0 echo "Creating crypto disklabel" disklabel -E sd0 < Also, keep in mind that anyone who has root access on > these machines has the ability to copy the key disk, the softraid metadata > with the encrypted disk keys and even the unencrypted disk encryption keys > once they're in memory... Of course. This is not to protect against ourselves, but to go from full production to "have the plug pulled and the hardware returned to the owner" in a matter of minutes. I fully understand the data is still readable by anyone who has managed to get hold of the keys. It is the tradeoff of not having time for even a single pass of dd of the main partition. -- Patrik Lundin
Re: crypto softraid and keydisk on same harddrive
On Wed, Oct 29, 2014 at 01:24:30AM +1100, Joel Sing wrote:
> On Wed, 29 Oct 2014, Joel Sing wrote:
> >
> > A CRYPTO key disk is slightly special in that it has softraid metadata but
> > is not technically part of the same volume (well, it is in some ways but it
> > is not in others). The problem in question occurs since installboot(8)
> > installs the first stage boot loader on each chunk that is a member of the
> > volume - in this case it installs first stage boot loader twice (once for
> > wd0a and again for wd0d). The second stage boot loader is installed in the
> > softraid metadata area for the sd0 volume, however in the case of a CRYPTO
> > key disk its metadata area does not end up with a copy of the boot of the
> > second stage loader (unlike, say a RAID 1 chunk). If the first stage boot
> > blocks are installed in the CRYPTO volume then the key disk, the boot
> > loader (in the PBR of wd0) will end up pointing at a boot storage area (of
> > the key disk) that does not contain the second stage boot loader. The fix
> > is to probably avoid installing the boot loader on the key disk.
>
> You could try this (only compile tested) diff:
>
> Index: i386_softraid.c
> ===
> RCS file: /cvs/src/usr.sbin/installboot/i386_softraid.c,v
> retrieving revision 1.2
> diff -u -p -r1.2 i386_softraid.c
> --- i386_softraid.c 9 Jun 2014 13:13:48 - 1.2
> +++ i386_softraid.c 28 Oct 2014 14:21:27 -
> @@ -42,6 +42,7 @@ voidsr_install_bootldr(int, char *);
> void
> sr_install_bootblk(int devfd, int vol, int disk)
> {
> + struct bioc_vol bv;
> struct bioc_disk bd;
> struct disklabel dl;
> struct partition *pp;
> @@ -56,6 +57,15 @@ sr_install_bootblk(int devfd, int vol, i
> bd.bd_diskid = disk;
> if (ioctl(devfd, BIOCDISK, &bd) == -1)
> err(1, "BIOCDISK");
> +
> + /* Skip CRYPTO key disks. */
> + /* XXX - pass volume in rather than volume ID. */
> + memset(&bv, 0, sizeof(bv));
> + bv.bv_volid = vol;
> + if (ioctl(devfd, BIOCVOL, &bv) == -1)
> + err(1, "BIOCVOL");
> + if (bv.bv_level == 'C' && bd.bd_size == 0)
> + return;
>
> /* Check disk status. */
> if (bd.bd_status != BIOC_SDONLINE && bd.bd_status != BIOC_SDREBUILD) {
>
> --
>
> "Action without study is fatal. Study without action is futile."
> -- Mary Ritter Beard
Any developer feel like looking at merging this diff? It seems jsing is
busy with other work. My interest in this is that it is helpful for
OpenBSD machines used at Dreamhack (http://dreamhack.se) to quickly
decommision them when the festival is over.
The original thread can be found here:
http://marc.info/?l=openbsd-misc&m=141435482820277&w=2
--
Patrik Lundin
Re: ksh version lies
On Sat, Mar 14, 2015 at 07:29:30PM +, Christian Weisgerber wrote: > > KSH_VERSION shouldn't be removed and if we want to tweak the value, > we need to leave the leading "@(#)PD KSH" alone, which is what > people will most likely match on. This is essentially the "Mozilla/5.0" > user agent issue... > Thank you for this information, a pull request against the ansible script is available here: https://github.com/ansible/ansible/pull/10466 -- Patrik Lundin
Re: ksh version lies
On Fri, Mar 13, 2015 at 10:48:56AM +0900, Pascal Stumpf wrote:
> On Thu, 12 Mar 2015 15:25:48 + (UTC), Christian Weisgerber wrote:
> > On 2015-03-12, Patrik Lundin wrote:
> >
> > >===
> > > elif [ -n "$KSH_VERSION" ]; then
> > > HACKING_DIR=$(dirname "${.sh.file}")
> > >===
> >
> > .sh.file and related dot variables are a ksh93 extension. I don't
> > think ksh88 supports this, so this is unportable even within the
> > ksh family. ... Actually, ksh88 doesn't have KSH_VERSION either if
> > I am to believe the comments in Sven Mascheck's famous script:
> >
> > http://www.in-ulm.de/~mascheck/various/whatshell/whatshell.sh.comments.html
>
> Exactly. The bug is that the script seems to equate the presence of
> KSH_VERSION to 'this is ksh93' without looking at its contents.
>
If ksh88 neither has KSH_VERSION or the .sh variables, could the
presence of KSH_VERSION mean "this shell is at least ksh93 equivalent"?
Maby this is an added incentive for tedu's patch that removes the
variable? If it had not have been set at all ansible would have been
happy :).
Anyway, I understand that removing such a variable could lead to other
fallout as the previous messages in this thread discusses. The sensible
way forward would be for me to look into how to decide if the version
string more specifically belongs to a ksh93 inspired ksh if present.
Thanks for your input!
--
Patrik Lundin
Re: ksh version lies
On Sun, Feb 15, 2015 at 09:00:27PM -0500, Ted Unangst wrote:
> ksh (and sh) have a version string embedded in them:
> @(#)PD KSH v5.2.14 99/07/13.2
>
> This is clearly a lie. We've added, removed, and fixed bugs and features since
> then. I first noticed the lie in the man page, then saw that it's also
> exported via the environment and other places.
>
I recently ran into a related problem when pulling the latest ansible
sources and trying to run ansible directly from a checkout:
===
$ . hacking/env-setup
ksh: hacking/env-setup[23]: ${.sh.file}": bad substitution
[...]
===
The script (env-setup) does this:
===
elif [ -n "$KSH_VERSION" ]; then
HACKING_DIR=$(dirname "${.sh.file}")
===
It seems the ksh in OpenBSD base does not contain the ".sh." that
some other versions have. Looking at http://www.manpagez.com/man/1/ksh/
there seems to be several listed under "Parameter Expansion."
Before trying to hack around this myself, would there be any specific
desired paths to solve the problem? I realize this is possibly not a
discussion well suited for tech@, but since I recall this discussion
mentioning the removal of $KSH_VERSION it seemed close enough.
Sorry for the noise otherwise.
--
Patrik Lundin
Re: rcctl(8): Fetch default service flags
On Fri, Oct 10, 2014 at 03:53:15PM +0200, Antoine Jacoutot wrote: > > Maby the expected results of our tools are different. My goal for the > > ansible module is that you either keep a specific set of flags in the > > > > playbook which will then get set if necessary, or you remove the flags > > and will instead get the system default. > > > > Not passing any arguments does not mean "do not modify any flags", it > > means "make sure we have the default flags". Because of this I will need > > That's backward. From what I know of Puppet and SaltStack, they work totally > different. They will never change anything on the system unless you intruct > them to. > In your case you want that the absence of a configuration knob (flags in this > case) resets what in rc.conf.local... I think that is *not* the element of > least surprise :-) > To me this means the tool would miss if I for whatever stupid reason felt the need to manually tweak rc.conf.localo on a box, later forgetting I had done so. In this case I would need to always specify flags, even default (empty) ones, to be sure all systems are configured the way they are supposed to. This seems to contradict the beauty of defaults. This is probably sliding into bikeshedding territory, so I will leave it at that (would happily discuss it offlist though) :). Regards, Patrik Lundin
Re: rcctl(8): Fetch default service flags
On Fri, Oct 10, 2014 at 03:05:40PM +0200, Antoine Jacoutot wrote: > > But you should not have to. > If you don't pass any flags to ansible, why is ansible looking at the output > of rcctl status to compare flags? > In saltstack, iirc what I implemented is that flags are only compared when > one actually sets some. > Maby the expected results of our tools are different. My goal for the ansible module is that you either keep a specific set of flags in the playbook which will then get set if necessary, or you remove the flags and will instead get the system default. Not passing any arguments does not mean "do not modify any flags", it means "make sure we have the default flags". Because of this I will need to check if the current set of flags are the default or not. Hope this makes some sense :). Regards, Patrik Lundin
Re: rcctl(8): Fetch default service flags
On Fri, Oct 10, 2014 at 01:50:52PM +0200, Antoine Jacoutot wrote: > > > > If I now run the tool again, still without any supplied arguments, it > > will compare the empty set of user supplied flags to "-tun 4" which > > always differs. So ansible will now think it needs to change something > > "forever" :). > > > > To solve this I need the default flags to compare to the output of > > 'status'. > > Well in this case, I think you should pass the flags you want to ansible -- > even if they are the same as the defaults. > I'm not very keen on adding a new knob... > This breaks the principle of least surprise. If you do not need to supply flags when calling rcctl in the shell you should not have to supply flags when using ansible. I fully understand if you do not want to add knobs. This only means I will need to replicate svc_default_enabled_flags() in my module. I would rather store as much logic as possible in rcctl itself to keep the overhead/upkeep low, but you can't get everything i guess :). Regards, Patrik Lundin
Re: rcctl(8): Fetch default service flags
On Thu, Oct 09, 2014 at 11:51:50PM +0200, Patrik Lundin wrote: > > To solve this I need the default flags to compare to the output of > 'status'. > ... I guess another solution could be if 'status' only showed flags that differed from the default. Regards, Patrik Lundin
Re: rcctl(8): Fetch default service flags
On Thu, Oct 09, 2014 at 11:25:58PM +0200, Antoine Jacoutot wrote: > > Sorry, I should probably have been more clear on the reason I need it :). > > > > The main issue from the ansible perspective is to know if we are _going_ > > to change something or not. The user may for example run ansible in > > --check mode where it should only report if it is about to change > > something or not. > > Ok but then I don't understand why you need to know the "default" > flags :-) > If you run rcctl status, it will tell you the current flags of the > daemon; if these differ from the new flags you want to pass ansible > then 'ansible --check' will report you that it will change the flags. > Which is correct, no ? > Or did I misundertand something (I probably did...). > The problem occurs when I try to manage a service like nfsd which has a default set of flags. Consider the following commands, which basically performs what ansible does when the user is not supplying any extra arguments: --- # rcctl status nfsd NO # rcctl enable nfsd # rcctl status nfsd -tun 4 # --- If I now run the tool again, still without any supplied arguments, it will compare the empty set of user supplied flags to "-tun 4" which always differs. So ansible will now think it needs to change something "forever" :). To solve this I need the default flags to compare to the output of 'status'. Regards, Patrik Lundin
Re: rcctl(8): Fetch default service flags
On Thu, Oct 09, 2014 at 10:58:34PM +0200, Antoine Jacoutot wrote: > > The module wants to figure out if it should reset the flags in > > rc.conf.local to the default set if no arguments are supplied by the > > user. > > Can you provide an example. Because if not arguments are supplied, according > to your previous mail, it should run like: > rcctl enable foobar flags > which will reset the flags anyway. > > > The problem with this is that there is no way to find out what the > > default flags are. This makes it hard to deal with a service like nfsd > > But why do you need that exactly? > Note that I am not against modifying rcctl, I am just trying to understand > the need... > Sorry, I should probably have been more clear on the reason I need it :). The main issue from the ansible perspective is to know if we are _going_ to change something or not. The user may for example run ansible in --check mode where it should only report if it is about to change something or not. Even when not running in --check mode the module needs to report if something was changed or not. Regards, Patrik Lundin
rcctl(8): Fetch default service flags
Hello, This is another question triggered by working on rcctl(8) support for the ansible service module. The module wants to figure out if it should reset the flags in rc.conf.local to the default set if no arguments are supplied by the user. The problem with this is that there is no way to find out what the default flags are. This makes it hard to deal with a service like nfsd where 'status' will return "-tun 4" by default or whatever the user has set previously otherwise. I noticed there is a function in rcctl already that finds this out: svc_default_enabled_flags(). Being able to call this via some argument to rcctl would solve my problem. I am leaving out a diff because I have no idea what a good name for such an argument would be, but just calling "svc_default_enabled_flags $svc" in the script seems to return what I need. Regards, Patrik Lundin
Re: rcctl(8): special services and flags
On Thu, Oct 09, 2014 at 10:04:44PM +0200, Ingo Schwarze wrote: > > A possible solution to this would be to relax the flags check in rcctl, > > so it only cares if there are actual flags supplied. See diff below for > > a suggestion on how to deal with this which seems to work. > > The first half of the patch seems pointless to me. > Why do you want to allow "disable foo flags"? > Or am i overlooking something? > I agree the first half may be pointless, I was only trying to be symmetrical in the handling of the flags keyword so it works both ways: --- # rcctl enable pf flags # rcctl disable pf flags --- I don't feel strongly about this though, either way is fine for my needs. > > The second half is ok schwarze@ if Antoine wants to commit, > though i'd slightly prefer the simplified version given below. > Looks good to me :). Regards, Patrik Lundin
Re: rcctl(8): special services and flags
On Thu, Oct 09, 2014 at 10:02:50PM +0200, Antoine Jacoutot wrote:
> >
> > The later behaviour causes a problem when modifying special services
> > like pf. When disabling pf a "pf=NO" is added to rc.conf.local as
> > expected, but when trying to enable it again it will fail because the
> > ansible module notices that flags are currently set ("NO"), and tries to
> > call "rcctl enable pf flags" which fails:
>
> Why is ansible appending flags in the first place when no flags are
> configured?
>
An example would be if the user started out with supplying "-s" to ntpd
and then changes his mind and removes the flag. The idea is to then call
rcctl with an empty "flags" argument to get the default set of flags
instead.
It was my understanding from the man page that this was the approriate
way to do it, am I mistaken?
Regards,
Patrik Lundin
rcctl(8): special services and flags
Hello,
While working on rcctl(8) support for ansible I have run into a
situation I am not sure how to deal with.
Basically, if the user has supplied arguments we append
"flags " and this works good.
If the user supplied no arguments, but there currently are flags set
in rc.conf.local we append an empty "flags" argument to reset the
default value.
The later behaviour causes a problem when modifying special services
like pf. When disabling pf a "pf=NO" is added to rc.conf.local as
expected, but when trying to enable it again it will fail because the
ansible module notices that flags are currently set ("NO"), and tries to
call "rcctl enable pf flags" which fails:
---
# rcctl enable pf flags
rcctl: "pf" is a special variable, cannot set "flags"
---
I am not sure how to deal with this properly since I do not want to
duplicate the _special_services variable in the module.
A possible solution to this would be to relax the flags check in rcctl,
so it only cares if there are actual flags supplied. See diff below for
a suggestion on how to deal with this which seems to work.
If I am going about this the wrong way any pointers are greatly
appreciated of course!
Regards,
Patrik Lundin
Index: rcctl.sh
===
RCS file: /cvs/src/usr.sbin/rcctl/rcctl.sh,v
retrieving revision 1.38
diff -u -p -u -r1.38 rcctl.sh
--- rcctl.sh1 Sep 2014 18:01:55 - 1.38
+++ rcctl.sh9 Oct 2014 18:17:56 -
@@ -274,10 +274,14 @@ fi
if [ -n "$flag" ]; then
if [ "$flag" = "flags" ]; then
if [ "$action" != "enable" ]; then
- _rc_err "${0##*/}: \"flags\" can only be set with
\"enable\""
+ if [ -n "$4" ]; then
+ _rc_err "${0##*/}: \"flags\" can only be set
with \"enable\""
+ fi
fi
if svc_is_special $svc; then
- _rc_err "${0##*/}: \"$svc\" is a special variable,
cannot set \"flags\""
+ if [ -n "$4" ]; then
+ _rc_err "${0##*/}: \"$svc\" is a special
variable, cannot set \"flags\""
+ fi
fi
if [ "$4" = "NO" ]; then
_rc_err "${0##*/}: \"flags NO\" contradicts \"enable\""
Re: autoinstall(8): remove "System hostname" from example
On Sat, Apr 26, 2014 at 07:21:28AM -0400, Kenneth Westerback wrote: > > Assuming you mean dhclient.conf and not dhcpd.conf, the hostname of > the system is not currently set by dhclient even if it is supplied. > The install process does cause dhclient to send the configured > hostname to the dhcpd server for it's own record keeping purposes. > I was thinking about the 'option host-name "foo";' at the end of autoinstall(8). From what I can tell this is picked up by get_responsefile() in /usr/src/distrib/miniroot/install.sub like so: 2118 # Prime hostname with host-name option 2119 hostname "$(sed -E '/^ *option host-name "(.*)";$/!d;s//\1/;q' $_lf)" I have installed a box with a recent snapshot and the resulting machine will be named after what is set in dhcpd.conf. Regards, Patrik Lundin
autoinstall(8): remove "System hostname" from example
Hello, I have tried out the autoinstall functionality and it worked great. The install log turning up as an email was a very nice touch. One thing that I was thinking about when looking at the examples in autoinstall(8) was that while "System hostname" is set in the response file example, it is also primed via the dhcpd.conf host example. Just setting it in dhcpd.conf will lead to one less place to keep track of while keeping the response file less host specific. Does this sound reasonable? Regards, Patrik Lundin Index: autoinstall.8 === RCS file: /cvs/src/share/man/man8/autoinstall.8,v retrieving revision 1.7 diff -u -r1.7 autoinstall.8 --- autoinstall.8 24 Feb 2014 23:43:26 - 1.7 +++ autoinstall.8 26 Apr 2014 09:48:48 - @@ -132,7 +132,6 @@ .Sh EXAMPLES A typical install.conf file will look something like this: .Bd -literal -offset indent -System hostname = server1 Password for root = $2a$14$Z4xRMg8vDpgYH...GVot3ySoj8yby Change the default console to com0 = yes Which speed should com0 use = 19200
slowcgi(8): small wording tweak
Hello, I just read slowcgi(8) and one of the sentences read a bit strange to me. Anyone agree? Regards, Patrik Lundin Index: slowcgi.8 === RCS file: /cvs/src/usr.sbin/slowcgi/slowcgi.8,v retrieving revision 1.5 diff -u -p -u -r1.5 slowcgi.8 --- slowcgi.8 12 Dec 2013 10:48:52 - 1.5 +++ slowcgi.8 19 Jan 2014 11:30:24 - @@ -33,11 +33,11 @@ opens a socket at .Pa /var/www/run/slowcgi.sock , owned by root:www, with permissions 0660. -It then +It will then .Xr chroot 8 to .Pa /var/www -and drops privileges to user +and drop privileges to user .Qq www . .Pp The options are as follows:
Re: NSD 4
On Mon, Nov 25, 2013 at 06:15:48PM +, Stuart Henderson wrote: > I've had one test report so far, has anyone else tested this? > > > Update notes (also repeated in the diff file): > > > > cd /usr/sbin && rm nsd-notify nsd-patch nsd-xfer nsd-zonec nsdc > > cd /usr/share/man/man8 && rm nsd-notify.8 nsd-patch.8 nsd-xfer.8 > > nsd-zonec.8 nsdc.8 > > chown _nsd /var/nsd/db/nsd.db > > install -o _nsd -g _nsd -d 750 /var/nsd/run/xfr > > mv /etc/nsd.conf to /var/nsd/etc/nsd.conf > > - needed to support reloads while in chroot > > printf '\nremote-control:\n\tcontrol-enable: yes\n' >> /var/nsd/etc.nsd.conf > > > > $EDITOR /var/nsd/etc/nsd.conf > > - if you have "include" lines, edit them to specify the *full* path e.g. > > "include /var/nsd/etc/nsd.local" - nsd strips the chroot prefix as needed > > > > - remove any old cronjobs that run "nsdc patch", this is no longer needed > > > > N.B. NSD now uses mmap() to access its database. From what I have read > > so far access is done just via the mmap rather than a mixture of that > > and write(), but I may have missed something, more eyes on this would > > be very welcome. > > > I have been testing this on sparc64 (though i notice now that i built a complete userland via "make build" instead of the specific make options above. Sorry if this messes with something.) Some things i ran into: There is a typo on the printf-line above: s,etc\.nsd.conf,etc/nsd.conf, And while nitpicking, maby the "to" in the mv line should be removed for easy copy-pasting. I needed to create a /var/nsd/etc directory (perms based on /var/named/etc/): # install -o root -g _nsd -d -m 750 /var/nsd/etc (Is it possible that the /var/nsd/run/xfr creation above misses a "-m")? I also believe you need some wider permissions on the /var/nsd/db/ directory in order to use the nsd-control addzone/delzone stuff. I added a pattern to the config: --- pattern: name: "slave" zonefile: "slave/%s.zone" --- ... and played around with: # nsd-control addzone example.com slave # nsd-control delzone example.com ... which caused errors like the following: Nov 25 18:49:58 crash nsd[21185]: could not create zone list /db/zone.list: Permission denied Nov 25 18:49:58 crash nsd[21185]: zone example.com could not be added Nov 25 18:52:10 crash nsd[21185]: could not open /db/zone.list~: Permission denied Nov 25 18:57:12 crash nsd[21185]: could not open /db/zone.list~: Permission denied I solved this personally with: # chown _nsd:wheel /var/nsd/db/ Wanting to write out the dynamically added zone also needs permissions (in my example config) for zones/slave/: # nsd-control write Nov 25 19:55:40 crash nsd[19519]: cannot write zone example.com file slave/example.com.zone~: Permission denied I solved that with (again based on my personal config): # chown _nsd /var/nsd/zones/slave I have not tested this a lot, but at least dig @127.0.0.1 works for the example.com zone. Just thought I should throw this info out there, I think it is great you are doing the work to get NSD 4 in base. Thanks a lot :). Regards, Patrik Lundin
md5: returns 0 when a file does not exist
Hello,
I noticed that md5(1) returns 0 when you target a file that does not
exist:
=
$ md5 foobar
md5: cannot open foobar: No such file or directory
$ echo $?
0
=
This seems wrong according to the man page, and I have looked at the
FreeBSD and Linux equivalent tool which returns 1 in this case.
I have attempted to write a patch that changes this behaviour. My
limited testing has been successful at least, see diff below.
Regards,
Patrik Lundin
Index: md5.c
===
RCS file: /cvs/src/bin/md5/md5.c,v
retrieving revision 1.54
diff -u -r1.54 md5.c
--- md5.c 4 Dec 2012 02:38:51 - 1.54
+++ md5.c 28 Mar 2013 14:09:43 -
@@ -194,7 +194,7 @@
TAILQ_HEAD(hash_list, hash_function);
void digest_end(const struct hash_function *, void *, char *, size_t, int);
-void digest_file(const char *, struct hash_list *, int);
+int digest_file(const char *, struct hash_list *, int);
int digest_filelist(const char *, struct hash_function *);
void digest_print(const struct hash_function *, const char *, const char *);
void digest_printstr(const struct hash_function *, const char *, const char *);
@@ -386,10 +386,10 @@
error += digest_filelist(*argv++,
TAILQ_FIRST(&hl));
} else if (pflag || argc == 0)
- digest_file("-", &hl, pflag);
+ error = digest_file("-", &hl, pflag);
else
while (argc--)
- digest_file(*argv++, &hl, 0);
+ error += digest_file(*argv++, &hl, 0);
return(error ? EXIT_FAILURE : EXIT_SUCCESS);
}
@@ -476,7 +476,7 @@
}
}
-void
+int
digest_file(const char *file, struct hash_list *hl, int echo)
{
struct hash_function *hf;
@@ -489,7 +489,7 @@
fp = stdin;
else if ((fp = fopen(file, "r")) == NULL) {
warn("cannot open %s", file);
- return;
+ return(1);
}
if (echo)
@@ -510,7 +510,7 @@
warn("%s: read error", file);
if (fp != stdin)
fclose(fp);
- return;
+ return(1);
}
if (fp != stdin)
fclose(fp);
@@ -523,6 +523,7 @@
else
digest_print(hf, file, digest);
}
+ return(0);
}
/*
Re: relayd(8) 'disable/enable table' support for relays
On Wed, Nov 17, 2010 at 02:35:11AM +1100, Jonathan Gray wrote: > Thanks, committed. It seems some more stuff was needed to make things stable. When requesting stuff from relays with disabled tables, relayd would fail with the follwing debug output: disable_table: disabled table 1 fatal: relay_from_table: no active hosts, desynchronized check_child: lost child: socket relay engine exited pf update engine exiting host check engine exiting terminating # The same thing would happen when a just-enabled-table recieved requests when the included hosts were still in an unknown state. This was due to a catch-all fatalx() in relay.c and the reason we hit it was because we failed to set table->up to 0 in the new IMSG_TABLE_DISABLE handler. The following patch fixes this (also setting it in the IMSG_TABLE_ENABLE handler for good measure as is done in enable_table() in pfe.c: http://dump.komsi.se/obsd/relayd/relayd-table2.patch This gives us the graceful "relay_from_table: no active hosts" debug log instead. Even though this seems to fix stability, there is still some strange stuff going on. When disabling tables in quick succesion, a table set up with ssl (both "listen on [...] ssl" and "forward to with ssl [...]") would _sometimes_ have table->up set to 1 even though "relayctl sh sum" would show all tables as disabled (and therefore give me the resources behind the relay). If the ssl part is relevant or not, I do not know. I guess it could also be a message-passing issue of some sort. The testing has been done with ftp(1) against http:// and https://, and i have also noted that there doesn't seem to be a decisive respone on the socket when relayd throws "relay_from_table: no active hosts". I base this on that ftp(1) will sometimes say "Receiving HTTP reply: Invalid argument" and sometimes "Receiving HTTP reply: Connection reset by peer" when testing a clear text socket. Doing the same against the SSL relay will throw "Improper response from " or "Error retrieving file:" followed by what looks like crypto junk. Just thought I would throw it out there while it was still fresh in my head. Regards, Patrik Lundin
Re: relayd(8) 'disable/enable table' support for relays
On Tue, Nov 16, 2010 at 01:48:51PM +0100, Patrik Lundin wrote: > > You will find the complete patch attached to this message for easy reference. > [...] > > [demime 1.01d removed an attachment of type text/x-diff] > I was hoping the attachment would not get eaten when added inline, sorry about that. I made the complete patch available here: http://dump.komsi.se/obsd/relayd/relayd-table.patch Regards, Patrik Lundin
relayd(8) 'disable/enable table' support for relays
>conf.id);
pfe_sync();
return (0);
@@ -768,9 +773,9 @@
int
enable_table(struct ctl_conn *c, struct ctl_id *id)
{
- struct rdr *rdr;
struct table*table;
struct host *host;
+ int n;
if (id->id == EMPTY_ID)
table = table_findbyname(env, id->name);
@@ -780,7 +785,7 @@
return (-1);
id->id = table->conf.id;
- if ((rdr = rdr_find(env, table->conf.rdrid)) == NULL)
+ if (table->conf.rdrid > 0 && rdr_find(env, table->conf.rdrid) == NULL)
fatalx("enable_table: desynchronised");
if (!(table->conf.flags & F_DISABLE))
@@ -792,6 +797,11 @@
host->up = HOST_UNKNOWN;
imsg_compose_event(iev_hce, IMSG_TABLE_ENABLE, 0, 0, -1,
&table->conf.id, sizeof(table->conf.id));
+ /* Forward to relay engine(s) */
+ for (n = 0; n < env->sc_prefork_relay; n++)
+ imsg_compose_event(&iev_relay[n],
+ IMSG_TABLE_ENABLE, 0, 0, -1,
+ &table->conf.id, sizeof(table->conf.id));
log_debug("enable_table: enabled table %d", table->conf.id);
pfe_sync();
return (0);
Now for the handling of IMSG_TABLE_DISABLE and IMSG_TABLE_ENABLE in relay.c
(borrowed from hce.c):
Index: relay.c
===
RCS file: /cvs/src/usr.sbin/relayd/relay.c,v
retrieving revision 1.123
diff -u -r1.123 relay.c
--- relay.c 12 Oct 2010 14:52:21 - 1.123
+++ relay.c 16 Nov 2010 12:02:04 -
@@ -2492,6 +2492,22 @@
host->flags &= ~(F_DISABLE);
host->up = HOST_UNKNOWN;
break;
+ case IMSG_TABLE_DISABLE:
+ memcpy(&id, imsg.data, sizeof(id));
+ if ((table = table_find(env, id)) == NULL)
+ fatalx("relay_dispatch_pfe: desynchronized");
+ table->conf.flags |= F_DISABLE;
+ TAILQ_FOREACH(host, &table->hosts, entry)
+ host->up = HOST_UNKNOWN;
+ break;
+ case IMSG_TABLE_ENABLE:
+ memcpy(&id, imsg.data, sizeof(id));
+ if ((table = table_find(env, id)) == NULL)
+ fatalx("relay_dispatch_pfe: desynchronized");
+ table->conf.flags &= ~(F_DISABLE);
+ TAILQ_FOREACH(host, &table->hosts, entry)
+ host->up = HOST_UNKNOWN;
+ break;
case IMSG_HOST_STATUS:
if (imsg.hdr.len - IMSG_HEADER_SIZE != sizeof(st))
fatalx("relay_dispatch_pfe: invalid request");
You will find the complete patch attached to this message for easy reference.
This was all developed, built and tested on 4.8, but the patches are against
-current.
If you think these patches doesn't suck and you wish to use them, I would very
much appreciate if you could also mention Linus Widstrvmer in the commit
message because he helped out a huge amount to makes these patches see the
light of day.
Thanks for a great OS :)
Regards,
Patrik Lundin
[demime 1.01d removed an attachment of type text/x-diff]
