Re: Migrate to different FS layout of OpenBSD
Kirill A. Korinsky writes: > Folks, > > I'm looking for a way to migrate to different layout some OpenBSD systems. > > So, questions: > 1. Has anyone done something like this before? > 2. Do you have any instruction or that to expect? Yes. What to expect? There is a very good chance data will be lost, so before you proceed back everything up. Of course no backup is complete without testing that it can be restored, so verify that you can turn your backup back into a working system. Because you now have a backup abandon the idea of doing shenanigans that will probably go wrong and install OpenBSD fresh on a set of discs formatted however you like then restore your backup. Matthew
Re: Security questions: Login spoofing, X11 keylogging, and sandboxed apps
Luke A. Call writes: > > On 2024-03-29 09:01:07-0400, James Huddle wrote: > > Exfiltrator. There's an 11-letter word that starts with "ex". X11. > > After a quick web search, I'm not sure I follow. Is that a reference to > a program that exfiltrates data after a computer is compromised? Can you > elaborate a little? I realize this is an ignorant question. In short, there is a well known shortcoming or feature depending on who you ask inherent in the X protocol's design where any application which uses the X server (ie. can access the tcp port or unix socket and has the correct xauth key, which is to say all of them) can request (and get) the ability to read all of the X events, which includes every key press and mouse movement in every application. Exfiltrator is 11 letters and we are at X protocol version 11. There are common mitigations against this problem, such as not giving strangers the ability to run unknown programs on your console. Matthew
Re: files are going missing
Files don't randomly disappear. Downloaders can set the date of downloaded files to the time the server reports. OpenBSD then deletes them because they are old. Don't use /tmp for long term storage. It's temporary. The clue is in the name. Matthew ps. as a general rule if something has been around for 50 years, is used by millions daily, runs a sizeable chunk of the internet, and it appears to be broken, you're probably holding it wrong.
xpdf
To those who agreed to include xpdf3 alongside the New! Improved! Slower! Gaudier! version 4, thank you! That was a horrible 30 seconds. Matthew
Re: Firefox problem
Prasad MN writes: > Does not work for me either -- I am on the latest snapshot and > Firefox fails with the same error as reported on the thread. > Same error for Tor Browser. It just takes patience. Or make. Surely you have a backup computer? The problem was noticed and the patch pushed to CVS on the 11th. By that time the previous build process was obviously already in progress. It completed by the 12th when its results were pushed to the web servers. The next snapshot build was kicked off and evidently completed a few hours ago because now _that_ has made its way to the web servers. Four days seems about what you might expect for building an entire operating system and everything that runs on it for however many platforms there are. In the meantime installing the firefox package from 7.4 worked, more or less, if building firefox doesn't seem like an appealing process (it didn't) or the text clients are awful (they are). This is what -current is for. Matthew
Re: Upgrading from 7.3 to 7.4 with sysupgrade
Mark writes: > "> That will never happen." > > And some serious reason? /usr/sbin/sysupgrade is 218 lines short _with_ comments and I for one like it that way. It's difficult to screw up by using it and easy to figure out what it did if you do. > It was a great idea indeed. :/ So was dividing the base system into sets. ... when a 20MB hard drive was considered "large" (heavy too). Reading this email has cost you more than the portion of the storage medium which would hold the sets you don't want to install. Matthew
Re: heck of a long time
Peter N. M. Hansteen writes: > On Wed, Aug 23, 2023 at 01:41:31PM +0200, Peter J. Philipp wrote: > > > > If this is a sensitive topic I apologize ahead of time. > > > > I'm wondering... can we have a change in the OpenBSD front page (to say): > > > > "Only two remote holes in the default install, in more than 26 years!" > > With a value that specific (26 years) there might be nagging for updates > every two releases (once per year). Minimal maintenance version: Only two remote holes in its long history ... so far. Matthew
Re: volatility or something like that in the future ?
Nick Holland writes: > Linux has become Windows Reinvented Badly. You seem to think > OpenBSD should become Linux Reinvented Badly. That's offensive. We prefer Unix Reimplemented... Matthew (Just kidding; it's great)
Re: Ryzen 9 (7x000) users: do you experience hangs?
Is it something in the water? Mike Larkin writes: > On Tue, Jul 18, 2023 at 08:09:11PM +0100, cho...@jtan.com wrote: > > This is completely unrelated to the question we asked. Please I mentioned that. Twice. Beginning with the very first words: > > Not really. But. Then summarising with: > > I don't know if that could help or even if it's related, but it can ^^^ (Emphasis added) The symptoms are somewhat similar, and there is a glaring common denominator. That is all. Although it seemed doubtful, just in case another data point could be helpful I hoped to provide enough information without drowning the list in noise so that people more familiar with the matter such as yourself could assess whether a deluge of data was warranted. Don't worry. I won't do that again. Matthew
Re: Ryzen 9 (7x000) users: do you experience hangs?
Not really. But. I have an APU2 which runs two VMs that do practically nothing, although the box itself is used actively. The VMs consistently, and without warning, hang in a way which matches the description "nothing new can be execed" although I recall being able to log in on the console. I noticed shortly after I installed the VMs in around May but I haven't got very far diagnosing it because it's a low priority. However there is a common denominator: AMD cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD G-T40E Processor, 1000.02 MHz, 14-02-00 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 2-way I-cache cpu0: 512KB 64b/line 16-way L2 cache cpu0: smt 0, core 0, package 0 Times two. As you say the existing processes seem to work fine right up until sshd is nearly (but not quite?) ready to fork: . . . debug1: SSH2_MSG_EXT_INFO received debug1: kex_input_ext_info: server-sig-algs= debug1: kex_input_ext_info: publickey-hostbo...@openssh.com=<0> debug1: SSH2_MSG_SERVICE_ACCEPT received Ordinarily it would next attempt authentication. Does sshd fork and drop privileges to do that? I don't know if that could help or even if it's related, but it can be reproduced with confidence. I can poke the box or its VMs any way that could shake some data loose. Matthew
Re: ntpd and ppm
Theo de Raadt writes: > J Doe wrote: > > > On 2023-07-04 17:27, Martin Schröder wrote: > > > > > Am Di., 4. Juli 2023 um 23:20 Uhr schrieb J Doe > > > : > > >> I checked: man ntpd and: man 2 adjfreq, and while: man 2 adjfreq > > >> mentions the same unit - "ppm" - it doesn't explain what that means. > > >> > > >> What does "ppm" stand for ? > > > > > > microseconds per second. > > > > Hi Martin, > > > > Ah, I see! From Google there was a link that referenced PPM with a > > different: ntpd implementation and it mentioned "Parts Per Million", but > > I was confused by that as I have only heard of Parts Per Million with > > pollution / chemistry ... but microseconds per second makes sense. > > You mean lime "1 in a million" is the same as "microseconds per second"? > > There's always jobs for people who can't do simple math. Is it that time of the month again? Matthew
Re: Minimum install size
Theo de Raadt writes: > Yoshihiro Kawamata wrote: > > > From: Janne Johansson > > Subject: Re: Minimum install size > > Date: Fri, 28 Apr 2023 09:09:49 +0200 > > > > > Do not assume "desireable" and "possible" are always the same. > > > > My point was whether the wording "installable on 512MB of storage" is > > appropriate to put in the OpenBSD 7.3 FAQ, and whether "desirable" and > > "possible" are the same is outside the discussion. > > No, it is optimistic oversell by the faq authors > > It should be realistic & accurate, or it should say nothing at all. To be fair the FAQ does cover itself by saying that squeezing into 512MB is "something for advanced users" and it looks like despite the march of time that can still just about be done. On the other hand I routinely run into problems (the obvious sort you expect) when I allocate just 2GB for OpenBSD. Storage is cheap and getting cheaper. I have more terabytes than I ever dreamed could exist just ... sitting on the desk, unused. You can fit it in 2GB or even 512MB if you really must but why? Even 10GB quickly fills up --- this workstation I'm on has 17GB in /usr/local and that's with me keeping it trim because the machine "only" has 128GB. So without further ado, here's some HTML. Matthew Index: faq/faq4.html === RCS file: /src/openbsd/cvs/www/faq/faq4.html,v retrieving revision 1.554 diff -u -p -r1.554 faq4.html --- faq/faq4.html 10 Apr 2023 02:55:09 - 1.554 +++ faq/faq4.html 30 Apr 2023 14:34:18 - @@ -412,9 +412,11 @@ When you get to the list of file sets, s Disk Partitioning -OpenBSD can be installed in as little as 512MB, but using a device that small -is something for advanced users. -Until you have some experience, 8GB or more disk space is recommended. +With a little extra work OpenBSD can be installed in as little as +2GB but such a small device isn't recommended even for advanced +users due to the effort required at every new release. Until you +have some experience, 20GB or more disk space is recommended which +includes room for some large packages. Unlike some other operating systems, OpenBSD encourages users to split their
Re: Help for another wiped out disklabel
Greg Thomas writes: > I just ran through a fresh 7.3 install onto sd0 on an old 6.8 laptop and I > have no idea what happened to the disklabel on sd1 (during the install I > only did an automatic disklabel on sd0). This is just a backup of my > current laptop so not the end of the world (unless my current laptop dies > before I have a chance to back it up again). Part of the solution I used previously to recover my trashed disklabel was a script to create a partition on the disklabel with every starting value (a simple brute force approach). This proved to be far too slow so I resorted to hacking scan_ffs but that's because I had other partitions and swap of unknown size to skip over first to find the /var/backup partition that I needed. Since your lost partition is at the beginning of the disc somewhere this shouldn't be much of a problem. The end sector doesn't really matter if you'll mount the partition read-only provided it's large enough; just don't run fsck on it. Something along the lines of: for k in `jot 2048`; do echo | disklabel -e sd0; mount -r /dev/sd1a /mnt && echo $k; umount /mnt; done Where is multi-line input to disklabel to delete and create partition a. Alternatively investigate disklabel's -R option. Then locate your disklabel backup, investigate -R if you didn't already, and restore it exactly. Matthew
Re: Mail Etiquette: Reply above or below
It makes it easier to know what part of the original message a response is in reply to. As a general rule you should reply in-line, quoting only the specific parts of a message your response is in reference to. Matthew Eric Johnson writes: > --- Original Message --- > On Tuesday, March 7th, 2023 at 03:50, Peter N. M. Hansteen > wrote: > > > For whatever reason, Microsoft's Outlook or possibly earlier Microsoft mail > > client products dragged in a convention of quoting the whole thread (even > > though > > those early clients did not in fact have the thread concept) and putting new > > text on top. > > Don't forget AOL. In the old UseNet days, AOLers seemed to > be the ones who most insisted on top posting and it drove the > rest of us crazy. > > I'm not positive, but I think that the AOL software handled > the mail and Microsoft came around to it somewhat later. > > I have come around to the point that I don't mind top posting > if the remarks pretty much stand on their own and only address > a single point. It even saves scrolling down to the bottom to > read the comments, especially if the person being responded to > didn't snip those parts that don't really relate to the comments > being made. > > But you are right that inline is the way to go for anything > suitably complicated in order to eliminate any chance of > someone else getting confused about what is being referred > to by the comment. > > In one web forum that I participate in, there are a few users > who will quote the message being replied to and then insert > their comments intermixed within the quoted part instead of > separating the quotes out in pieces to avoid the reader from > being seriously confused over who said what. I really hate > it when they do that. > > So in response, I sometimes write my replies using the > character code sequences such as for J. That way, it > forces those who can't be bothered to separate their comments > from the quoted text to keep their text separate. > > I think that the main point is that the purpose of writing > is so that others may understand what you had to say. The > more difficult that someone makes it to decipher what they > wrote, the more people won't even bother with them. > > Eric Why?
Using scan_ffs to recover a disklabel
I broke my TV.
My TV is a monitor powered by a laptop running OpenBSD and in trying
to diagnose a problem which turned out to be in the NAS I managed to
fry the disklabel.
How?
Well, being unimportant the machine is also the guinea pig for
snapshot builds and other experiments so I thought I might try
removing the problem (thus confirming it's to do with running a
snapshot) by reverting to 7.2 stable.
I copied bsd.rd from a stable machine, booted into that and installed
over the top of the snapshot.
The install worked fine but nothing much ran and / filled up with
core dumps. Bummer.
Oh well, easy enough to fix, just move the system files out of the
way and reinstall. It's getting late but the OpenBSD installer's a
breeze and it should be all done and config files merged in 15
minutes.
Well it wasn't 15 minutes. I did the wrong thing and blasted the
disklabel.
The partitions weren't formatted. I knew this because I'd popped
into the installer's shell and replaced /sbin/newfs with an empty
file (what /bin/true used to be). The files were safe.
After stepping back and using another machine to get the music going
again I remembered that scan_ffs can find partitions when the
disklabel is lost. Using that I can either recover it in full, or
at least find /var with the backup.
Well the numbers scan_ffs gave me were gibberish. The manual warns
that it only looks for ffs1 partitions, not ffs2, but I ran it
anyway and tried poking variations on the numbers it gave me into
disklabel. That didn't work.
In the end I opened up scan_ffs.c to look at how it does its scan.
It proceeds in disk-block-sized chunks (512K) and applies each to
a 'struct fs' as defined in /usr/include/ufs/ffs/fs.h. Unfortunately
as the manual states it only considers ffs1 partitions, marked by
FS_MAGIC aka FS_UFS1_MAGIC. While there's a FS_UFS2_MAGIC printing
the location in which it was found didn't give me the result I
expected...
By this time, since I was figuring out scan_ffs and not looking for
my missing /var, I was running it over a small disk image where I
knew there was a partition at block 64, but the modifed scan_ffs
said the first partition was on block 192.
I thought that was strange but maybe there's a ffs1-like non-super-block
which points to the real ffs2 block later on. Hoping this was the
case I ran a scan over the whole disk printing each block that had
a FS_UFS2_MAGIC signature, offset by the amount to feed to disklabel.
Armed with a list of matching blocks (there were around 300 when I
stopped scanning after I was confident /var was found or missed) I
wrote a script to delete and recreate a partition beginning at each
potential block (the length doesn't matter) and try to mount it
(read only!). Since there were only a few blocks to check I scanned
the output by eye, found /var and copied the disklabel backup out
of it. With that it was a simple matter to restore the correct
disklabel, check the partitions and recover the system in full.
To obtain the list of blocks I added this clause after the main
test in scan_ffs.c:
else if (sb->fs_magic == FS_UFS2_MAGIC) {
printf("ufs2 @ %lld\n", (blk*512+n)/512 - 128);
This script fiddled with the disklabel to find a partition which
worked (this changes the real disklabel):
while read maybe; do
echo 'd d\na d\n'$maybe'\n\n\nw\n' | disklabel -E sd0
>/dev/null 2>&1
echo -n "$maybe: "
mount -r /dev/sd0d /mnt && ls /mnt /mnt/moved
umount /mnt 2>/dev/null
done
There are certainly better ways.
Restoring the disklabel is described in the manual:
disklabel -R sd0 /tmp/disklabel.sd0.current
The fully-integrated build system made testing changes to scan_ffs
a breeze even though my dev box is on the snapshot and the recovery
system was stable. Putting the snapshot back on the telly took much
less than 15 minutes.
It's possible scan_ffs could be simply extended to print potential
ffs2 partitions (there are a few more checks it could make to whittle
down the result) if the 128-block offset is constant across platforms.
Cheers,
Matthew
Re: Live stick / cd from official sources
Daniele B. writes: > Thanks for this one, Bodie. > > In my little, simple prospective from year 2023 there is the hope that we are > going to overcome soon > all these sayings we are telling us about *nix. The way such shortcomings might be overcome is to produce the code which replaces or fixes them. > And however, my opinion, ... is irrelevant, and moreover unintersting. Your opinion is not interpreted by my CPU, which interprets code. > Obviously it is my own interest Indeed. And your own interest will be best served by writing your own code. > is it so ridiculous to ask Yes. And also rude. Your hardware, your money, your use. You make sure it works for you. It's nobody else's responsibility to write the code for their own hardware. > I think that we should shorten this "formal gap" also because, Assuming this formal gap --- I didn't read that --- is related to software you're given for free not doing something you want it to do, you'd close this gap by writing the code to make it do so. > Can we arrange these situation in a better bsd fashion? There is no need to rearrange anything, you just need to write the code. It's really not rocket science. Matthew
Re: 回复: 回复: 回复: 回复: Softraid crypto metadata backup
Nathan Carruth writes: > permanently and irrevocably destroy all data on your entire disk”. This is a feature. More so, it's the very point in an encrypted filesystem. If you haven't planned for this failure scenario then what are you doing using a device which *by design* can irrevocably trash its contents in an instant? Matthew
Re: equivalent to linux/serial.h?
Justin Muir writes: > Hello, > > Just attempting to compile SDRAngel from source and I'm getting some errors > in the process. > > The latest is: "linux/serial.h" missing. Is there an equivalent I can > point to on OpenBSD? > > I'm also having difficulties with the dab-cmdline library. The compile goes > haywire with a bunch of mismatches in header definitions. Is there an > equivalent to dab-cmdline in OBSD?? OpenBSD has two files named serial.h: llama$ find /usr/include/ /usr/src/ -name serial.h /usr/src/gnu/usr.bin/binutils/gdb/serial.h /usr/src/usr.bin/dig/lib/isc/include/isc/serial.h llama$ But nothing named dab-like, even in ports. llama$ find /usr/src/ /usr/ports/ -name dab\* llama$ Matthew
Getting to know malloc
In a personal project I need a low-level memory allocator and as I don't know how one works and need to read Knuth 6 times to begin to misunderstand it, I decided to learn how the allocator I use every day works: OpenBSDs malloc. To do this means reading the code and making notes describing what I understand is happening. As I've been doing a lot of programming recently using Knuth's Literate Programming technique I decided I'd make those notes while also converting it to Literate C. I decided to upload the first draft of this file in case it interests anybody (or if anybody wants to help improve the text!) The files are too big to send out on the mailing list at 85 and 442 KB each so I pushed them to the interweb. http://zeus.jtan.com/~chohag/malloc.w http://zeus.jtan.com/~chohag/malloc.pdf Although not the main goal, the malloc.w source file can be used to generate a malloc.c file which works in place of the real malloc.c. The result is almost identical except that because the contents of malloc.c end up being in a different order the object file produced is also ordered differently (and about 60 bytes shorter! I think the optimiser got lucky). To generate the pdf or C source requires CWEB, included as part of TeXlive (which is huge). I think the package texlive_texmf-minimal-2021 is enough. C: ctangle malloc.w TeX (first step): cweave malloc.w PDF (second step): pdftex malloc.tex I plan at least one more run through this for my own understanding as there's quite a bit that I skimmed over and cutting the code into pieces was done quite haphazardly (not to mention with zero understanding at the beginning) but I have no other plans for this beyond maybe a bit of a polish, however if there's any interest then I'm happy to put a bit of elbow grease into making this a more coherent description of how the allocator works (including diving into thread_private.h --- yech!) and keeping it up to date. Finally, as I went through I noted a few improvements which could be made as well as other questions (not all written down), eg. some routines use u_short while others use ushort and other little things like that. Some require a deeper dive into CVS history so I'll come out with a comprehensive list some time over Christmas. Cheers, Matthew
Re: Possible typo in fw_update
Andrew Hewus Fresh writes:
> On Sun, Dec 11, 2022 at 08:06:24PM -0500, Rob Whitlock wrote:
> > On line 408, fw_update has the expression ${LOCALSRC:#file:}. The parameter
> > substitution ${name:#word} is not documented in the manual page for ksh yet
> > its behavior seems to be equivalent to ${LOCALSRC#file:}. Assuming this is
> > a typo, a patch is provided to remove the colon. If it is not a typo, could
> > someone explain what this syntax does?
>
> It was a typo, committed, thanks!
>
>
> > Is this was a typo however, and this parameter substitution is not
> > officially supported, why did ksh not complain?
>
> Not having read it, I assume the implementation reads the : and sets a
> flag that says "must be be NULL" for the -, +, =, and ? substitutions
> and the validation that the next character is one of those four is
> missing.
It does this:
/* allow :# and :% (ksh88 compat) */
if (c == ':') {
*wp++ = CHAR, *wp++ = c;
c = getsc();
}
... introduced in lex.c 1.11 in 1998. I think it's safe.
> An email to bugs@ with this question might get the attention of folks
> who are more familiar with ksh internals and whether fixing this being
> too accepting is worth the code and the likelihood of breaking scripts
> with typos like this one.
>From prior excavation deep in the bowels of yylex:
${-expansion expects a variable name and modifiers. The
name is scanned for by get_brace_var below and then
modification by ``#'' or ``%'' is detected. ``:#'' and
``:%'' are also accepted for compatibility with ksh88.
This seems like a good opportunity for shameless self-promotion of
the full excavation at http://zeus.jtan.com/~chohag/ksh/ (section
347 "Detect ${-expansion", page 147).
Matthew
Re: redirection puzzle
rsyk...@disroot.org writes:
> Dear list,
>
> ...
>
> but this does not work:
>
> odin:~$ echo 1 | tee $(tty) | sed 's/1/2/'
> 2
> odin:~$
>
> I do not understand why...
The position of the tty command in the pipeline means that its
standard input is not the terminal:
$ echo $(tty)
/dev/ttyp8
$ echo | echo $(tty)
not a tty
You can either capture the output of tty separately or get ksh to
do the work itself:
$ foo=$(tty)
$ echo "$foo"
/dev/ttyp8
$ echo 1 | tee $foo | sed s/1/2/
1
2
or
$ stdsplit() {
> while IFS= read -r line; do
> eval echo '"$line"' >&$1
> echo "$line"
> done
> }
$ echo 1 | stdsplit 2 | sed s/1/2/
1
2
Leaving stderr alone (I couldn't help myself; that's why there's
an eval in there now):
$ exec 3>&1 # Must happen outside the pipeline
$ echo 1 | stdsplit 3 | sed s/1/2/
1
2
$ exec 3>&- # Or don't do this.
Matthew
Re: Locking network card configuration
Theo de Raadt writes:
> > > + for _hn in /etc/hostname.??:??:??:??:??:??; do
> > > + _mac=`echo $_hn | cut -c 15-31`
_mac=${_hn#/etc/hostname.}
> > > + _if=`ifconfig | grep -B 1 $_mac | head -n 1 | awk -F ": "
> > > '{print $1}'`
mac2dev() {
# This got long
ifconfig | while IFS= read _line; do
if [[ "$_line" = [a-z]!(\ *):* ]]; then
_dev=${_line%%:*}
elif [[ "$_line" = *lladdr*$1* && $_dev != vlan* ]]; then
echo $_dev
fi
done
}
_if=$(mac2dev "$_mac") # or just _if=$(mac2dev ${_hn#*.})
IFS needs to be cleared for read otherwise initial whitespace is
stripped from _line.
Note that the vlan devices need to be excluded. Are there other
circumstances which could confuse this in ifconfig's output?
It could probably return immediately after printing.
Matthew
Re: sysupdate and space check
Luke A. Call writes:
> On 2022-10-26 11:57:23-, Stuart Henderson
> wrote:
> > On 2022-10-24, Peter Fraser wrote:
> > > I make a stupid mistake; I didn't check partition sizes before doing a
> > > sysupgrade.
> > > sysupgrade ran out of space or /usr in the middle of the upgrade.
> > > I know I should have checked first but it would be nice if sysupgrade did
> > > warn me.
> > > The site was a 20-minute drive away, and their down time was a lot longer
> > > then I expected.
> >
> > It would be nice, but it's tough to reliably test this without actually
> > extracting the files (and a warning with many false triggers wouldn't be
> > all that much use either ..)
>
> Thanks for that info, it is interesting.
>
> I'm just me, but would definitely prefer a warning that
> suggests a potential problem and says what to
"Might be too small" isn't very helpful without context. And where's
the unnecessary, complicated and fragile pipeline?
How about this:
# Find the length of the string encoding the size of the smallest
# physical partition (just using /usr and/or / would be boring):
smallest=$(df | awk '/^\// {print $2}' | sort -n | head -n1 | wc -c)
# Complain if it's too small:
if (( $smallest < 10 )); then
echo "Your storage is partitioned like it's the 20th century."
fi
For the real modern touch you can make the test abort unconditionally.
if (( $smallest < 10 )); then
echo "You should not be thinking about partitions."
echo "Aborting in case you hurt yourself."
exit 0 ## Return 0 because errors are scary.
fi
Matthew
Re: ksh: documented substitution behavior contradicts actual behavior
Kastus Shchuka writes:
> On Sun, Oct 16, 2022 at 11:48:35AM +0100, cho...@jtan.com wrote:
> > So given $X:
> >
> > $ X=' A : B::D'
> >
> > Parameter substitution:
> >
> > $ ( IFS=' :'; dump $X )
> > $VAR1 = 'A';
> > $VAR2 = 'B';
> > $VAR3 = '';
> > $VAR4 = 'D';
> >
> > read substitution:
> >
> > $ echo "$X" | ( IFS=' :'; read a1 a2 a3 a4; dump "$a1" "$a2" "$a3"
> > "$a4" )
> > $VAR1 = 'A';
> > $VAR2 = '';
> > $VAR3 = 'B';
> > $VAR4 = ':D';
> >
> > It does look like read, which uses its own expansion routine, has
> > a bug: a2/VAR2 should be 'B' (or 'B::D') not ''.
>
> Not sure if it is a bug or a feature.
I can't think of a good reason why the output from these commands
should be different. The manpage section describing read states
clearly that it should be using the same splitting algorithm:
"separates the line into fields using the IFS parameter (see
Substitution above)".
The diff brings them into line with each other and I think accounts
for all the edge cases.
Matthew
Index: c_sh.c
===
RCS file: /src/datum/openbsd/cvs/src/bin/ksh/c_sh.c,v
retrieving revision 1.64
diff -u -p -r1.64 c_sh.c
--- c_sh.c 22 May 2020 07:50:07 - 1.64
+++ c_sh.c 17 Oct 2022 09:59:21 -
@@ -253,6 +253,7 @@ c_read(char **wp)
int expand = 1, savehist = 0;
int expanding;
int ecode = 0;
+ int hardws = 0;
char *cp;
int fd = 0;
struct shf *shf;
@@ -376,9 +377,21 @@ c_read(char **wp)
break;
if (ctype(c, C_IFS)) {
if (Xlength(cs, cp) == 0 && ctype(c, C_IFSWS))
- continue;
+ continue; /* Trim leading space. */
+ if (!ctype(c, C_IFSWS)) {
+ /* Do not finish this variable
+* on non IFS whitespace if the
+* previous variable has
+* trailing IFS whitespace.
+*/
+ if (hardws) {
+ hardws = false;
+ continue;
+ }
+ } else
+ hardws = true;
if (wp[1])
- break;
+ break; /* Finish scanning this
variable. */
}
Xput(cs, cp, c);
}
Re: ksh: documented substitution behavior contradicts actual behavior
Kastus Shchuka writes:
> On Sat, Oct 15, 2022 at 11:42:17PM -0300, Lucas de Sena wrote:
> > Hi,
> >
> > After trying to split a string into fields delimited with colons and
> > spaces, I found this bug in how ksh(1) does substitution. The actual
> > behavior contradicts what other shells like bash and mksh do and also
> > contradicts its own manual.
> >
> > Running the following on other shells (say, bash) prints "/foo/bar/".
> > This command splits the string " foo : bar " into two fields: "foo"
> > and "bar", considering colon and space as delimiters.
> >
> > echo " foo : bar " | {
> > IFS=": "
> > read -r a b
> > printf -- "/%s/%s/\n" "$a" "$b"
> > }
> >
> > However, running the same command in OpenBSD ksh(1) (or sh(1)) splits
> > the string into "foo" and ": bar".
>
> This is because the last parameter (b) is a concatenation of two fields.
> Parsing
> is done properly if you add c to the read command:
>
> + echo foo : bar
> + IFS=:
> + read -r a b c
> + printf -- /%s/%s/%s/\n foo bar
> /foo//bar/
>
>
> >
> > The manual ksh(1) provides the following, similar example:
> >
> > > Example: If IFS is set to “:”, and VAR is set to
> > > “A:B::D”, the substitution for $VAR
> > > results in four fields: ‘A’, ‘B’, ‘’ (an empty field), and ‘D’.
> > > Note that if the IFS parameter is set to the NULL string, no field
> > > splitting is done; if the parameter is unset, the default value of
> > > space, tab, and newline is used.
> >
> > Let's try it:
> >
> > echo " A : B::D" | {
> > IFS=" :"
> > read -r arg1 arg2 arg3 arg4
> > printf -- '1st: "%s"\n' "$arg1"
> > printf -- '2nd: "%s"\n' "$arg2"
> > printf -- '3rd: "%s"\n' "$arg3"
> > printf -- '4th: "%s"\n' "$arg4"
> > }
> >
> > bash(1) splits the line into the following fields:
> >
> > 1st: "A"
> > 2nd: "B"
> > 3rd: ""
> > 4th: "D"
> >
> > This is actually the expected output, as described in the manual.
> >
> > However, running the same command in OpenBSD ksh, prints this:
> >
> > 1st: "A"
> > 2nd: ""
> > 3rd: "B"
> > 4th: ":D"
> >
> > A completelly different thing.
> > The same occurs with OpenBSD sh(1).
>
> What you observe is the result of the next paragraph in the man page
> after the example you quoted:
>
> Also, note that the field splitting applies only to the immediate result
> of the substitution. Using the previous example, the substitution for
> $VAR:E results in the fields: `A', `B', `', and `D:E', not `A', `B', `',
> `D', and `E'. This behavior is POSIX compliant, but incompatible with
> some other shell implementations which do field splitting on the word
> which contained the substitution or use IFS as a general whitespace
> delimiter.
Actually you need to look further into the manual since the word
splitting is performed not by parameter substitution but by read:
Reads a line of input from the standard input, separates the line
into fields using the IFS parameter (see Substitution above), and
assigns each field to the specified parameters.
This is why adding an extra variable to read above (and here) makes
it capture the remainder of the string.
For example:
$ alias dump="perl -MData::Dumper -e 'print Dumper @ARGV'"
$ dump a b c
$VAR1 = 'a';
$VAR2 = 'b';
$VAR3 = 'c';
$ ( IFS=:; dump $PATH )
$VAR1 = '/bin';
$VAR2 = '/sbin';
$VAR3 = '/usr/bin';
$VAR4 = '/usr/sbin';
$VAR5 = '/usr/X11R6/bin';
$VAR6 = '/usr/local/bin';
$VAR7 = '/usr/local/sbin';
$VAR8 = '/usr/games';
So given $X:
$ X=' A : B::D'
Parameter substitution:
$ ( IFS=' :'; dump $X )
$VAR1 = 'A';
$VAR2 = 'B';
$VAR3 = '';
$VAR4 = 'D';
Similarly:
$ fn() { dump "$@" ); fn $X
$VAR1 = 'A';
$VAR2 = ':';
$VAR3 = 'B::D';
$ fn() { dump "$@"; }; ( IFS=' :'; fn $X )
$VAR1 = 'A';
$VAR2 = 'B';
$VAR3 = '';
$VAR4 = 'D';
read substitution:
$ echo "$X" | ( IFS=' :'; read a1 a2 a3; dump "$a1" "$a2" "$a3" )
$VAR1 = 'A';
$VAR2 = '';
$VAR3 = 'B::D';
$ echo "$X" | ( IFS=' :'; read a1 a2 a3 a4; dump "$a1" "$a2" "$a3"
"$a4" )
$VAR1 = 'A';
$VAR2 = '';
$VAR3 = 'B';
$VAR4 = ':D';
$ echo "$X" | ( IFS=' :'; read a1 a2 a3 a4 a5; dump "$a1" "$a2" "$a3"
"$a4" "$a5" )
$VAR1 = 'A';
$VAR2 = '';
$VAR3 = 'B';
$VAR4 = '';
$VAR5 = 'D';
It does look like read, which uses its own expansion routine, has
a bug: a2/VAR2 should be 'B' (or 'B::D') not ''.
Matthew
Re: proper way to grow softraid partition
It's easier by far not to muck about trying to resize partitions. If you can mount each drive (old and new) in an operating system that isn't using them then that's your best bet and that's not so hard to arrange. Mount the old partition structure in /old, create new larger partitions on the new drive mounted on /new and rsync -a /old/ /new/ (note the trailing /). After that you will need to install the boot code if the drive is used for booting which it probably is. I can't remember how to do that but it's no doubt performed in https://cvsweb.openbsd.org/src/distrib/miniroot/install.sub or its machine-dependent counterpart install.md (location varies). It's also in the manpages. installboot(8) looks promising. Sorry but I'm not going to provide instructions to do something I don't remember how to do and haven't tested. If you want to set up RAID or don't want to figure out how to install the boot blocks, install anew on the new larger possibly-RAIDed drives, install the same set of packages and copy /home and a few files from /etc to get a practically-identical installation. Matthew
Re: Re: Re: What’s new in OpenNSD 7.0 NYC*Bug meeting
harrywea...@tutanota.com writes: > > > A few among the myriad: > > https://www.tomsguide.com/news/zoom-security-privacy-woes > > https://jonathanhays.me/2020/04/04/zoom-insecurity/ > > https://www.reddit.com/r/technology/comments/ftkb69/zooms_security_and_privacy_problems_are/ > > But, perhaps you're comfortable with that. > We're all different.Cheers! Internet service provider doesn't know how to internet. News at 11. They're not insecure (except by accident), they're incompetent. Just like everyone else. Also the company seems to be more ham-fisted in its approach to public relations than Zuckerbook. If your response to incompetence on the internet is to flee somewhere with competence* and thus ignore its hidden mistakes, then may I interest you in this fine bridge? Use whatever it is to your heart's content. Adverts are unhelpful. The question was "do you want to join our zoom conference" not "what should we use for internet conferencing". Matthew [*] I don't know which thing you promoted but whatever it is, its security flaws haven't been found yet. Just like zoom's weren't until the entire world descended upon it en masse.
Re: Re: What’s new in OpenNSD 7.0 NYC*Bug meeting
harrywea...@tutanota.com writes: > > > > I wouldn't trust Zoom any further than I'd trust Skype. > Cheers! Wouldn't trust it to do what? It already doesn't work on OpenBSD (does the browser version work though? Never tried) so it's being kept away from your crown jewels in the sort of tightly locked-down enclave that linux needs to keep its guts inside itself anyway, so what's the risk? Matthew
Re: pkg_add -u failure; WAS: OpenBSD 7.0 released, Oct 14
Oh and it's also worth noting that despite that massive cock-up, the box is still (now) running just fine on this frankenhybrid and serving its git repositories and running its crons, all entirely hands-off and automated: # uname -a && uptime OpenBSD smoke.datum 7.0 GENERIC#224 amd64 4:29AM up 10:49, 2 users, load averages: 0.05, 0.02, 0.01 That's how engineering works. Take that, devops. Matthew
Re: pkg_add -u failure; WAS: OpenBSD 7.0 released, Oct 14
Stuart Henderson writes: > On 2021-10-14, cho...@jtan.com wrote: > > Turns out, one of my less important boxes was still on 6.8. Whoops. > > > > After two sysupgrades, this is the result of pkg_add -u: > > > > quirks-4.53 signed on 2021-10-12T20:12:39Z > > Can't install cairo-1.16.0 because of libraries > >|library pixman-1.40.0 not found > > That file is in xserv70.tgz so you shouldn't be having that problem unless the > untar failed. Does the file exist (should be in /usr/X11R6/lib)? Are you ok > for > disk space in /usr/X11R6? Bingo. I was even told about it in the email I ignored (there's nothing wrong with *69): Installing base70.tgz91% |*** | 275 MB00:01 ETAtar: Failed write to file ./usr/share/relink/kernel.tgz: No space left on device tar: Failed write to file ./usr/share/relink/usr/lib/libc.so.96.1.a: No space left on device tar: Failed write to file ./usr/share/relink/usr/lib/libcrypto.so.47.0.a: No space left on device tar: Failed write to file ./usr/share/snmp/mibs/OPENBSD-CARP-MIB.txt: No space left on device tar: Failed write to file ./usr/share/snmp/mibs/OPENBSD-PF-MIB.txt: No space left on device Installing base70.tgz99% |* | 301 MB00:00 ETAtar: Failed write to file ./usr/share/zoneinfo/CST6CDT: No space left on device tar: Failed write to file ./usr/share/zoneinfo/Europe/Paris: No space left on device tar: Failed write to file ./usr/share/zoneinfo/Europe/Zaporozhye: No space left on device tar: Failed write to file ./usr/share/zoneinfo/Pacific/Fiji: No space left on device Installing base70.tgz 100% |**| 302 MB00:14 Installation of base70.tgz failed. Continue anyway? [no] no Time to reinstall on a bigger disc. Thanks for the pointer, that saves me some perplexed digging around. Matthew btw Some of the space used on /usr will be old libraries (it's at least as old as 6.8, clearly), but for the record it looks like the minimum sizes on amd64 are approx. 1.25GB for /usr/!(X11R6|local), 240MB for /usr/X11R6 and <75MB for everything else if the box isn't doing a great deal.
pkg_add -u failure; WAS: OpenBSD 7.0 released, Oct 14
Turns out, one of my less important boxes was still on 6.8. Whoops. After two sysupgrades, this is the result of pkg_add -u: quirks-4.53 signed on 2021-10-12T20:12:39Z Can't install cairo-1.16.0 because of libraries |library pixman-1.40.0 not found | /usr/X11R6/lib/libpixman-1.so.38.4 (system): bad major Direct dependencies for cairo-1.16.0->1.16.0 resolve to png-1.6.37 glib2-2.68.4 lzo2-2.10p2 Full dependency tree is libiconv-1.16p0 png-1.6.37 lzo2-2.10p2 pcre-8.44 libffi-3.3p1 sqlite3-3.35.5p0 gettext-runtime-0.21p1 xz-5.2.5 python-3.8.12 glib2-2.68.4 bzip2-1.0.8p0 Can't install texlive_base-2020p0 because of libraries Direct dependencies for texlive_base-2020p0->2020p0 resolve to harfbuzz-2.9.1 cairo-1.16.0 graphite2-1.3.14 libiconv-1.16p0 png-1.6.37 ghostscript-9.07p7 clisp-2.49p5 dvi2tty-5.3.1p0 detex-2.8.1 gd-2.3.2 texlive_texmf-buildset-2020p0 psutils-2.06 libpaper-1.1.28 ps2eps-1.68p0 zziplib-0.13.62p1 desktop-file-utils-0.26 lcdf-typetools-2.108p0 texlive_mktexlsr-2020p0 icu4c-69.1p0v0 t1utils-1.42 texlive_synctex-2020p0 Full dependency tree is detex-2.8.1 pcre-8.44 libevent-2.1.11 jbig2dec-0.11 libiconv-1.16p0 png-1.6.37 icu4c-69.1p0v0 gnutls-3.7.2 texlive_mktexlsr-2020p0 libnettle-3.7.3 avahi-libs-0.8p1 texlive_synctex-2020p0 libunistring-0.9.7 psutils-2.06 ghostscript-fonts-8.11p3 texlive_texmf-buildset-2020p0 zziplib-0.13.62p1 ijs-0.35p3 dvi2tty-5.3.1p0 libunbound-1.13.2 gd-2.3.2 graphite2-1.3.14 cairo-1.16.0 p11-kit-0.24.0 libffi-3.3p1 zstd-1.5.0 desktop-file-utils-0.26 libidn2-2.3.0p0 libtasn1-4.17.0 clisp-2.49p5 cups-libs-2.3.3.2p1 harfbuzz-2.9.1 xz-5.2.5 gettext-runtime-0.21p1 dbus-1.12.20p1v0 sqlite3-3.35.5p0 tiff-4.3.0 gmp-6.2.1p0 ps2eps-1.68p0 ffcall-1.10p5 libpaper-1.1.28 giflib-5.1.6 p5-IPC-Run3-0.048p0 lz4-1.9.3p0 lzo2-2.10p2 libsigsegv-2.12 ghostscript-9.07p7 lcdf-typetools-2.108p0 libwebp-1.2.1 t1utils-1.42 lcms2-2.12 bzip2-1.0.8p0 glib2-2.68.4 python-3.8.12 jpeg-2.1.1v0 Couldn't find updates for cairo-1.16.0 texlive_base-2020p0 Couldn't install cairo-1.16.0 texlive_base-2020p0 This will not be difficult to fix; remove and reinstall will probably do it. If this is the result of me skipping pkg_add -u on the 6.9 hop then there's nothing to see here but I've done the same thing a few times before without incident (I expect problems if I skip base releases, not so much with ports) so if this problem's unexpected, well, here it is. In other news, quite a few other headless hands-off servers' upgrades were absolutely seamless. Thank-you! Matthew
Re: 4K display, teeny-tiny things
Joe Gidi writes: > > Picked up a 4K display (LG 27UPS650) and it's gorgeous. Bright colors, > > crisp, lovely. The console fonts and some application fonts are now > > dialed in WRT size. > > > > But application menu bars have tiny icons and tiny titles, and their > > man pages don't address that. Do those settings live in libraries I'm > > not used to tweaking? > > > > -- > > > > Edward Ahlsen-Girard > > Ft Walton Beach, FL > > Hi Ed, > > The Arch Linux Wiki page on HiDPI is a good resource for this: > > https://wiki.archlinux.org/title/HiDPI > > Personally, I am using the following settings in my .Xresources file to > scale things to a usable size and get a mouse pointer I can actually see > (I'm using a 4k 27" display as well): > > Xft.dpi: 144 > Xcursor.size: 32 > Xcursor.theme: Adwaita This "problem" is proving quite entertaining on a ~13" laptop. I don't use that machine for much so I mostly ignore it (it helps that it has a touch screen that "just works") but the issue on other (much larger) 4K screens driven by OpenBSD has been resolved with a simple application of xrandr's --scale option. Going from memory, the invocation is something like "xrandr --output --scale " where a rate of 0.5 or 0.666 has proven most effective. Older window managers will need to be reloaded/restarted after xrandr changes. I don't know if this is the "right" solution but then again I don't know if a right solution can ever include X. Matthew
Re: dhcp issues
Theo de Raadt writes: > Sonic wrote: > > > Having some issues after a sysupgrade to the latest snapshot (of this > > writing) - OpenBSD 6.9-current (GENERIC.MP) #131. > > > > Seems the base change to dhcpleased/resolvd has presented some issues. > > This is intentional. > > We are moving from a model ... > > Towards a model where ... > > dhclient will remain available ... > > Because the default configuration is changing. For what it's worth, this is why I find it helpful to subscribe to bugs@ and others even though I don't participate in the discussions there. I was trying to figure out why the dhcp/autoconf changes didn't surprise me since I couldn't see any reference to them in the upgrade/release notes. Then I remembered that I'd seen the chatter regarding it a few months back and, dhcp being a core component, researched around said chatter to see what changes I'd have to plan for. Remember OpenBSD is made by the OpenBSD developers [mostly] FOR the OpenBSD developers* and that it's given to the rest of us is largely an added bonus. It simply makes sense therefore to be privy to their discussions in order to stay most up-to-date regarding OpenBSD's progress. And sometimes, unfortunately, what the developers already know (or what's buried in documentation somewhere and thus "solved") and what the users want to be told are not the same thing. 6 months is longer than it looks. Matthew [*] This is not the whole story and I'm not speaking on OpenBSD's behalf, I'm trying to being concise.
Re: Centralized logging
he...@ezaquarii.com writes: > On 2021-04-24 22:50, li...@mailbox.org wrote: > > Do you have any best / bad practices at hand regarding OpenBSD and > > optionally the syslogd / tools it ships with? > > The main issue with remote logging is that your log messages could be > lost > when destination is unreachable. Neither syslog(3) nor the standard it implements makes any attempt to provide a facility in which log messages are guaranteed to be delivered and recorded reliably. There is no way for logging code to respond to errors which occurred in the logging system while submitting the log message as is the case with any other I/O. If that's a concern then logging may not be the appropriate solution. "The syslog() function shall send a message to an implementation-defined logging facility, which *MAY* log it in an implementation-defined system log ... (or a bunch of other optional things)" (emphasis added) > ... That said, there are some systems (as mentioned) which attempt to do so anyway which I've found to work pretty well on the whole. Matthew
Re: Full disk encryption including /boot, excluding bootloader?
cipher-hea...@riseup.net writes:
>
> On Linux you can do the following:
>
> Hard drive:
> { [1MB unencrypted GRUB bootloader partition] [Rest of hard drive entirely
> encrypted] }
>
> Then the only parts of the (x64) computer that are unencrypted are the BIOS
> and GRUB.
This is how it already does it with the exception that the unencrypted
data are not in a regular partition. Instead the unencrypted
bootloader exists within the space allocated for the disklabel (and
the MBR on x86) which then locates and decrypts the partition
containing the kernel.
> You can then move the GRUB offline if you wish, execute it externally.
>
>
> Is something like this possible on OpenBSD?
I have briefly looked into locating the unencrypted parts of OpenBSD's
bootloader on a seperate detachable disc, as I had managed to cobble
together previously, but the kernel is told where its root partition
is in quite a different way from Linux and I decided I didn't want
to trawl through x86 real mode assembly any more.
It can be done of course but you may have to hack at the bootloader
to make it work. I only did it with Linux to prove that I could not
because it was useful.
Matthew
Re: SSIZE_MAX
Raymond, David writes: > I am confused about SSIZE_MAX and read(2)/write(2). The POSIX > SSIZE_MAX is something like 2^15 -1. This seems to be a real > limitation when writing to a TCP/IP socket, as I learned from > experience. However, much larger reads and writes seem to be possible > to files and UNIX sockets (pipes). This makes me uneasy, given the > warning in the man pages for read(2)/write(2). > > Any insight on this topic would be appreciated. I would guess this is part of the reason why ssize_t was invented - so that half of the numeric range could be wasted in order for a function to be able to return -1, and/or ridiculous notions of symmetry. Looking in /usr/src/sys/lib/libsa/read.c shows that different types of file descriptor get their own read implementation (f->f_ops->read) which I'm not awake enough to track down. read(2) states: ... The system guarantees to read the number of bytes requested if the descriptor references a normal file that has that many bytes left before the end-of- file, but in no other case. Which suggests to me that the implementations for files and network sockets are quite different and that, unsurprisingly, the version for files is able to make a lot of assumptions and shortcuts that the networking code path cannot. Note that the manual also includes in the list of potential errors: [EINVAL] nbytes was larger than SSIZE_MAX. which is totally unqualified - ie. nbytes should not be larger than SSIZE_MAX in *any* case. Also nbytes is a size_t while the function's return value is ssize_t. This all comes to you pre-coffee. Take it as you will. Matthew
Re: sysupgrade woes on beaglebone black
Jan Stary writes: > - I can't figure out how to pass the -x option that sets $UU > (and thus makes the timer reset before each set is installed). You don't. http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/distrib/miniroot/dot.profile.diff?r1=1.42=1.43 Matthew
Leaving OpenBSD (with patch)
Some people have needs that OpenBSD doesn't meet. Of course the logical thing to do is to adapt it to meet them or to use something which does but to some -- in line with the general complexication that's progressing nowadays -- this simple solution is not enough and the need to announce one's inadequacy to the world in passive aggressive tones arises. Indeed this happens so commonly that it has become something on the order of a FAQ, and in order not to have to eat my own words from the other day I've spent actual time in the other text editor doing some actual hacking (I know, right?!?) and include this diff for the developers' consideration. I have taken the liberty of assuming you want to be at least moderately polite as you tell people to kindly fuck off. My apologies if that's an oversight; I can re-do it if you wish. Matthew cvs diff: Diffing . Index: faq1.html === RCS file: /home/flask/src/openbsd/cvsync/www/faq/faq1.html,v retrieving revision 1.238 diff -u -p -r1.238 faq1.html --- faq1.html 2 Oct 2019 15:40:06 - 1.238 +++ faq1.html 8 Jan 2020 16:12:30 - @@ -29,6 +29,7 @@ FAQ - Introduction to OpenBSD Migrating to OpenBSD Reporting Bugs Supporting the Project + Flouncing Out @@ -415,3 +416,46 @@ contribute. If you're a student, talk to your professors about using OpenBSD as a learning tool for Computer Science or Engineering courses. + +Flouncing Out + + +If the bug or other general but il-described annoyance you've recently +encountered has not been immediately fixed by the volunteers who +create OpenBSD and provide it for free and at their own expense for +your personal and frequently unthanked benefit, you may feel that +simply leaving quietly and using whatever system you wish because it's +not as if anyone even wants to stop you is not enough. In +that case you can post a goodbye message to one or more mailing lists +expressing your feelings in a last-ditch passive aggressive attempt to +make developers, by-standers and the peanut gallery such as your's +truly feel sorry for your self-imposed plight or whatever it is you're +after (nb. although cross-posting is usually considered bad +netiquette, a blind-eye is turned to it when flouncing out in a huff + in the case of extreme outrage non-OpenBSD mailing lists may +be copied in). + + +The most common variants on this theme, which the OpenBSD project +provides free of charge for you to use or adapt as you wish for this +or indeed any other purpose, are included here. A popular adaptation +is to refer to the alternative obliquely with terms such as "the other +camp" or "the enemy". + + + If OpenBSD won't adopt thing then I will have to + use alternative instead + (a popular variants on this reads "won't make thing + the default"). + Other people feel the same; I can't put up with it and have to + use alternative instead. + It's presumed that the popularity of this variant is the hinted + suggestion that more users will eventually bugger off and is + being offered as a good-will gesture a reminder to the + developers that things will eventually get better. + I would prefer to use OpenBSD but I can't because reason. + unsubscribe + + + +Good-bye. Your help has certainly been appreciated.
Re: OpenBSD's extremely poor network/disk performance?
Hamd writes: > It's 2020 and it's -still- sad to see OpenBSD -still- has the > ... lists full of the uninteresting type of wine and that their > twitterings -still- don't include any code. Yes. Yes it is. Can't say much for the performance of a suite of servers which have all been taken down to handle the security threat du jour. Matthew
Keep up the good work (was: Re: But there is Fossil...)
Stuart Henderson writes: > On 2020/01/05 00:33, go...@disroot.org wrote: > > January 5, 2020 2:24 AM, "Roderick" wrote: > > > > > On Sun, 5 Jan 2020, go...@disroot.org wrote: > > > > > >> so I don't understand what's wrong with FreeBSD and OpenBSD. > > > > > > I do not see a problem in CVS. > > > > Sure, but I started this thread because of OpenBSD's plan > > to migrate to Git. > > > > What plan? The plan which the OP would be aware doesn't exist were he to have bothered reading the FAQ he decided had too many words. Throwing away 30 years of work is A-OK, even expected, in this brave new CADT world so the alternative -- foundation technology should not be ripped out willy-nilly -- is an idea they simply cannot have. At this point it's clear he's either trolling or wilfully retarded. Either way not worth continuing with. To end positively I will add that a simpler git front-end, for want of a better term, will be a useful addition to the space of revision control tools. It's looking good so far. Keep it up. Matthew
Re: But there is Fossil...
go...@disroot.org writes: > Git is the most popular VCS (and most ugly), meanwhile > there are people who prefer to reimplement it because > they don't like its license... FreeBSD is working on OpenGit, > OpenBSD is working on Game of Trees, but why reimplement > the wheel instead of using a better solution: Fossil? > > [snip 3 paragraphs of indecent exposure] How convenient that there is a tradition of collecting together the questions that are asked frequently into a location that's easy to find. A list of "Frequently Asked Questions", if you will. I'd never even heard of Game of Trees until your email yet I've already been able to answer all of your questions by reading it's own god-damn website. https://gameoftrees.org/faq.html Read The Fucking FAQ Matthew
Re: What do you use to generate invoices on OpenBSD?
Mikolaj Kucharski writes: > Hi, > > Do you generate invoices on OpenBSD? What do you recommend? If you have I use nmh to compose an email to my accountant saying something along the lines of "please generate the next invoice for work X at company Y" and a few hours or days later an invoice -- an opaque object with bureaucratic purposes I am more than happy to keep encapsulated in their own domain, which is firmly not mine -- shows up in my inbox. It even gets automatically forwarded to the client! Other email software would also work. Matthew
Re: Re-organising partitions without re-installation
Stuart Longland writes: > > 16 partitions: > > #size offset fstype [fsize bsize cpg] > > a: 268416 64 4.2BSD 2048 16384 2097 # / > > b: 373010 268480swap# none > > c: 167772160 unused > > d: 413056 641504 4.2BSD 2048 16384 3227 # /tmp > > e: 435744 1054560 4.2BSD 2048 16384 3390 # /var > > f: 5006848 1490304 4.2BSD 2048 16384 12958 # /usr > > h: 4403456 6497152 4.2BSD 2048 16384 12958 # > > /usr/local > > i: 2138976 10900608 4.2BSD 2048 16384 12958 # /usr/src > > j: 2746048 13039584 4.2BSD 2048 16384 12958 # /usr/obj > > k: 986208 15785632 4.2BSD 2048 16384 7674 # /home > > Question is, how do I re-organise this space? There is sufficient space > there. /usr/obj and /usr/src are pretty much unused. /usr/local could > be made smaller too as could /home. Copy contents of /home, if any, to /var; Remove partitions i, j and k, replacing with a single large i to mount at /home; format new, larger partition i and restore the contents of /home from the backup; update /etc/fstab. Alternatively back up the contents of /usr/local as well and replace partition h with a larger one if you don't need a /home (except that now sysupgrade does, so...). Reboot not required although you will need to stop/start anything holding files open. Matthew
Re: [sh] Single quote in comment withing subshell buggy
Richard Ulmer writes: > Hi, > when there is a single ' in a comment within a subshell, I get this > error: foo[6]: no closing quote > > Here is an example script to reproduce the problem: > > foo=$( > # It's bar: > echo bar > ) > echo $foo This is certainly not the best way to do this but it does the job: ~/src/ksh [OpenBSD 6.6] [ksh]flask@void$ /bin/ksh void$ foo=$( > # quote: ' > echo bar > ) > ^D /bin/ksh: no closing quote ~/src/ksh [OpenBSD 6.6] [ksh]flask@void$ ./ksh void$ foo=$( > # quote: ' > echo bar > ) void$ echo $foo bar void$ In particular it just reeks of kludge, which I'm not happy with because according to the comment two-dozen lines up it's already a kludge. The loop is lifted from the beginning of the same function, where regular comments are skipped. Matthew --- lex.c.~1.78.~ Mon Jan 15 16:58:05 2018 +++ lex.c Sat Dec 14 10:55:06 2019 @@ -496,6 +496,12 @@ statep->ls_scsparen.csstate = 4; ignore_backslash_newline++; break; +case '#': +ignore_backslash_newline++; +while ((c = getsc()) != '\0' && c != '\n') +; +ignore_backslash_newline--; +break; } break;
Re: cron output direct to mbox without smtpd?
Andrew Kanaber writes: > Hi, > > I'm setting up an embedded machine that won't be able to send mail to > the internet and it seems excessive to leave smtpd running just so root > can receive cron job output, but I can't see a way to cut smtpd out of > the delivery chain because mail.local doesn't implement sendmail-style > command-line options (in particular it doesn't have the -t option to > extract the recipient from the message headers) so I can't use it in > place of smtpctl in /etc/mailer.conf. It may seem that way but consider: in order to write to the file a sequence is going to be followed by whatever cron kicks off which is incredibly similar to that which is already being done by smtpd, only it's one you're going to have to write and manage yourself instead of being "just there" from day one and kept up to date by a bunch of developers who weirdly want to just produce safe, stable code for free. Why balk? > Is there some other way to do this? Is there a reason I've missed that > this is actually just a bad idea? I recommend doing nothing; that way this problem will solve itself by virtue of having already been solved and you can do something interesting, ie. literally anything other than email. Do you really need the extra few bytes of memory that a dud process takes up? Matthew
Re: sysupgrade to 6.6 failed at comp66.tgz
> You can't seriously be calling "-x* -game*" an unsupported configuration ?
> Seems to me
> like a sensible thing to do on any box that's going to be headless for its
> entire life
> and only ever accessed via SSH (or text console at a push).
Lines 159-160 of /usr/sbin/sysupgrade read as follows:
SETS=$(sed -n -e 's/^SHA256 (\(.*\)) .*/\1/' \
-e '/^INSTALL\./p;/^bsd/p;/\.tgz$/p' SHA256)
This is followed by ~45 lines which download, verify and extract
them. The entire thing from that point takes up less than two
thirds of this small laptop screen.
It would have been quicker to write a patch to include the desired
functionality than create this email thread.
Here's a quick-and-dirty thing I just made up:
ed /usr/sbin/sysupgrade
/^SETS=/s//: ${SETS:=/
+s/$/}/
wq
Now you can, possibly, set SETS in the environent to override what
sysupgrade will even consider.
Matthew
Re: Disabling laptop display & turning off suspend on lid close
Mathijs Hengst writes: > > You can turn off the screen via X: > > xset dpms force off > > (I found this on google in 2/3 minutes, so you might want to improve > your google-foo.) It looks to me like his google-foo is working just fine. Question asked and answered, no? Matthew
Re: sysupgrade to 6.6 failed at comp66.tgz
mabi writes: > Hi, > > - reason why it failed? It cannot remove /usr/include/machine because it is not empty. > - what should I do now? retry to upgrade with sysupgrade? Empty /usr/include/machine. > - re-install the whole system? If you like. It will certainly empty out /usr/include/machine. > - maybe sysupgrade needs to be patched to avoid this issue? Probably not. sysupgrade has assumptions baked in to it which have evidently been rendered invalid either by another tool or by the person using them. That tool is where the patch most likely ought to be directed. Matthew
Re: Modifying installXX.iso via script
Thomas Bohl writes: > Am 17.11.2019 um 19:51 schrieb cho...@jtan.com: > > Thomas Bohl writes: > >> > >> Now I want to go the extra step and automate the modification of the > >> installXX.iso. > > > > I have put an insane amount of work into exactly this, also with > > an eye to portably directing the process to other operating systems > > and hosting environments. > > Thank you for your quick response. It works now. Even better that the > tools in base are enough. > > > > > I'd be very interested to hear more about what your working on but > > Nothing special. Only private stuff. I want to move from to-do lists to > scripts. I believe the buzzword is "infrastructure as code" :-) That is indeed one of the many. Personally I call it "my job" and am doing my level best to replace myself with a very small shell script. Currently down to ~3000 lines. Matthew
Re: Modifying installXX.iso via script
Thomas Bohl writes:
>
> Now I want to go the extra step and automate the modification of the
> installXX.iso.
I have put an insane amount of work into exactly this, also with
an eye to portably directing the process to other operating systems
and hosting environments.
I'd be very interested to hear more about what your working on but
meanwhile I think the command you're looking for is some variant
on this:
mkiso() {
# Create new iso
# From src/distrib/amd64/cdfs/Makefile
if on_openbsd; then
OSREV=$os_version # For easier copy pasta
mkhybrid -a -R -T -L -l -d -D -N -o "$iso_fn" -v -v\
-A "OpenBSD ${OSREV} amd64 autoinstall CD" \
-P "Copyright (c) `date +%Y` Theo de Raadt, The OpenBSD project" \
-p "Theo de Raadt " \
-V "OpenBSD/amd64 ${OSREV} boot-only CD" \
-b ${OSREV}/amd64/cdbr -c ${OSREV}/amd64/boot.catalog\
"$s_where"/cd
# -a all-files
# -R Rock Ridge
# -T TRANS.TBL
# -L Allow .-file
# -l allow 32char
# -d Omit trailing period
# -D not use deep directory relocation, ... Use with caution.
# -N Omit os_version numbers ... Use with caution.
# -o "$iso_fn"
# -v -v verbose
# -b boot_image
# -c boot_catalog
else
die_unsupported build/target combination
fi
}
mkhybrid and xorriso are basically the same tool in ways I can't
quite remember right not but could probably be persuaded to. An
invocation of one can be systematically converted into an invocation
of the other.
Enjoy.
Matthew
Re: Boot failure on XPS 13/9380 (but bsd.rd works)
I'd quite like to debug this problem. I'm looking through the code now to find out where I can inject some sort of printf-like statement to glean some information about what it's [not] doing and may eventually even get somewhere. I'll continue to do this regardless because I'm bored and I just spent a crapload of money on this thing and I'll be damned if it's going to not work on me and I want to use _this_ OS goddamnit, but if anyone can point me to resources to read or other hints about how to debug code running at such a low level before the OS has had a chance to take over, they would be greatly appreciated. I've been coddled for a long time and working on the bare metal like this is alien to me. Thanks, Matthew ps. Apologies if the list threading is screwed up. I can't reply to my own messages apparently.
Boot failure on XPS 13/9380 (but bsd.rd works)
As per the subject, bsd.rd boots and the installation proceeded as usual. Another laptop saved from ever booting the mess it came preinstalled with. Yay. Subsequently rebooting results in the following (bsd.sp does the same with different addresses): probing: pc0 mem[632K 475M 255M 208M 137M 150080M] disk: hd0 >> OpenBSD/amd64 BOOTX64 3.46 boot> booting hd0a:/bsd: 12748104+2941960+34+0+708608 [986153/ I tried booting the 6.5 installer to see if I could find a point between in which it broke but it stops every time after the kernel's penultimate line (between 'scsibus2 at softraid0: 256 targets' and reporting the root device). Interestingly 6.6 also did this once which was seemingly related to having warm-booted immediately prior but it only did it the once whereas 6.5 seems to be consistent. Nevertheless I wasn't paying attention to what the 6.6 installer was doing at the time so I'll look into that some more. I traced the boot process through to loadfile in libsa so I know that it's stuck while reading the ELF symbols (it gets at least as far as the first PROGRESS line after "Now load the symbol sections themselves") but that's probably obvious to whoever knows the boot code. Personally I haven't much clue what should be happening and it's clearly not happening as it should anyway so I don't know what to poke at to get more clues to fall out. The below was extracted by running sendbug -P from within the installed OS (chroot) while running the 6.6 bsd.rd and then doing whatever crazy thing I'm going to need to do to get them onto here. It complained about a lack of /var/db/acpi/* so if they're useful and can be generated from the ramdisk kernel then I can get them too. The dmesg is from the installer's /var. Matthew OpenBSD 6.6 (RAMDISK_CD) #349: Sat Oct 12 11:03:52 MDT 2019 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD real mem = 16924401664 (16140MB) avail mem = 16407494656 (15647MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.2 @ 0xe (101 entries) bios0: vendor Dell Inc. version "1.5.0" date 06/03/2019 bios0: Dell Inc. XPS 13 9380 acpi0 at bios0: ACPI 6.1 acpi0: tables DSDT FACP APIC FPDT FIDT MCFG SSDT BOOT SSDT HPET SSDT SSDT UEFI LPIT SSDT SSDT DBGP DBG2 SSDT SSDT MSDM SLIC DMAR SSDT NHLT TPM2 BGRT acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz, 7517.90 MHz, 06-8e-0c cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 256KB 64b/line 8-way L2 cache cpu0: apic clock running at 24MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG0) acpiprt2 at acpi0: bus -1 (PEG1) acpiprt3 at acpi0: bus -1 (PEG2) acpiprt4 at acpi0: bus -1 (RP01) acpiprt5 at acpi0: bus -1 (RP02) acpiprt6 at acpi0: bus -1 (RP03) acpiprt7 at acpi0: bus -1 (RP04) acpiprt8 at acpi0: bus 1 (RP05) acpiprt9 at acpi0: bus -1 (RP06) acpiprt10 at acpi0: bus 2 (RP07) acpiprt11 at acpi0: bus -1 (RP08) acpiprt12 at acpi0: bus -1 (RP09) acpiprt13 at acpi0: bus -1 (RP10) acpiprt14 at acpi0: bus -1 (RP11) acpiprt15 at acpi0: bus -1 (RP12) acpiprt16 at acpi0: bus 3 (RP13) acpiprt17 at acpi0: bus -1 (RP14) acpiprt18 at acpi0: bus -1 (RP15) acpiprt19 at acpi0: bus -1 (RP16) acpiprt20 at acpi0: bus -1 (RP17) acpiprt21 at acpi0: bus -1 (RP18) acpiprt22 at acpi0: bus -1 (RP19) acpiprt23 at acpi0: bus -1 (RP20) acpiprt24 at acpi0: bus -1 (RP21) acpiprt25 at acpi0: bus -1 (RP22) acpiprt26 at acpi0: bus -1 (RP23) acpiprt27 at acpi0: bus -1 (RP24) acpiec0 at acpi0 acpiec at acpi0 not configured acpipwrres at acpi0 not configured acpipwrres at acpi0 not configured acpipwrres at acpi0 not configured acpipwrres at acpi0 not configured acpipwrres at acpi0 not configured acpipwrres at acpi0 not configured acpicpu at acpi0 not configured acpitz at acpi0 not configured acpipwrres at acpi0 not configured "PNP0A08" at acpi0 not configured acpicmos0 at acpi0 "INT3403" at acpi0 not configured "INT3403" at acpi0 not configured "INT3403" at acpi0 not configured "INT3403" at acpi0 not configured "INT3403" at acpi0 not configured "INT34BB" at acpi0 not configured "ELAN2930" at acpi0 not configured "DELL08AF" at acpi0 not configured "INT3403" at acpi0 not configured "PNP0C14" at acpi0 not configured "PNP0C14" at acpi0 not configured "PNP0C14" at acpi0 not configured
Re: vi in ramdisk?
U'll Be King of the Stars writes: > This has gotten me thinking about whether line-based editing is really > the best abstraction for simple editors. Yes. Yes it is. You can prise ed out of my cold dead hands. I don't get where the desire for an editor in the installer comes from. If you have even the barest scraps of a system you can boot a full kernel and get a much richer environment to work in. The installer kernel itself contains much of what's necessary to run the installed binaries. boot -s. It's a thing. If any tools should be added to the installer it's something for network interrogation because that gives you more scope for dealing with odd scenarios *before* you have an installed system, but what's already there was apparently enough to get over whatever that problem was I encountered. > > The power of ed is in the regular expressions, search and substitution. The power of ed comes from the power of unix that it runs within not any particular string matching technique. It is a simple tool which does one thing, does it well, operates as a pipeline on text streams, etc. It would still have that power with any other string matching technology or even some other obscure addressing mode. > I assumed that the canonical reference for ed was K, "The Unix > Programming Environment". But since then I have discovered this book: > > https://mwl.io/nonfiction/tools#ed > > When I return home I will buy it. (I'm overseas at the moment.) > > What are some other good books for learning ed? How about online > resources, e.g., FTP sites with collections of interesting scripts. I assumed the canonical reference for ed was ed(1). Well I guess the canonical reference would be the contents of /usr/src/bin/ed but I'm not about to go trawling through that when there's some stellar documentation sitting right there. > I'm particularly interested in its history, usage idioms, different > implementations, multilingual capabilities, and using it as a vehicle > for mastering regular expressions to the point that they are second nature. I would recommend perl for this, not ed. ed it a text editor. Perl is a pattern matching engine with a turing complete programming environment hanging off the back of it. It's adapted (some might say warped) the language that represents regular expressions in strange ways but the machinery that's been built around it is fantastically easy to use in a "get out of the way" sense, leaving you to concentrate on the arcana of regular expressions. Deciding why one would want to do that is left as an exercise for the reader. But absolutely do keep on top of the differences between perl's regexes and regular regular expressions as described in re_format(7). Matthew
Re: Downgrade 6.6 to 6.5
Theo de Raadt writes: > I have some sort of X1rev6 and I don't see the problem. > > The situation is you have the hardware, and you also have the sourcecode, > and the repository to traverse investigate the problem. > > That sounds hard, until you give it a try. To be fair, it *is* hard. You have to have some understanding of how the magic rock you've blindly devoted yourself to works and how to encant the magical prescriptions that instruct it, which require learning such esoteric arts as "reading" and "thinking" and "logic". These are not things which come easily to many. The fact that all the required information is at everyone's fingertips and literally begging for attention notwthstanding. Matthew
Re: What is the relationship between fdisk and disklabel?
dmitry.sensei writes: > Why offset in disklabel for a partition is different from fdisk output? > 423202816 and 433358194 Something wrote the MBR and/or disklabel incorrectly. Probably a repartitioning or other data shuffling process gone wrong. > When I add label for partition 3 as in fdisk output i get overlapping error. Slight aside but let's get this out of the way: Unfortunately the terminology is confusing and contradictory between the unixes and BSDs. fdisk arbitrarily divides the disc into up to 4[*] partitions. There is no technical reason why they should by disjoint but that way lies madness. FreeBSD calls these slices. A partition of type 0xA6 is OpenBSD and if it contains a disklabel that is parsed for *its* definition of partitions. These are a different type of partition from the MBR's. OpenBSD does a reasonably good job of blurring the distinction during use which helps until the distinction matters, as now. On the whole non-unix OSs, including linux, do not have an equivalent of these (). There is also no technical reason why the disklabel partitions should be disjoint or why they should be within the *guidelines* laid out by the MBR-partitions, although that way lies further madness. The OpenBSD-partitions described by the disklabel are *not* relative to the MBR-partition which has type 0xA6 but to the *whole disc*. That's why label c starts at offset 0 and a starts at, usually, 64 or 2048. It needs to skip the MBR and other administrivia. Note that that has nothing to do with why fdisk's reported size and disklabel c's are different. The answer is don't think about it. MBR-partition types other than 0xA6 are, by the kernel at run-time, assigned effective disklabel-partitions starting at i (that is one MSDOS MBR-partition becomes i; I've no empirical experience with discs containing more or what happens if i is already allocated but I can make an educated guess...). > fdisk >0: EFI Sys [2048: 1126400 ] >3: FAT12[ 211014485:222343709 ] >4: OpenBSD [ 433358194:566856989 ] > disklabel > a:553568256423202816RAID > c: 10002152160 unused > i: 1126400 2048 MSDOS Depending on where exactly the disklabel is stored you may be unable to get away with adjusting MBR-partition 4's offset. If the kernel and bootloader find the disklabel based on the offset of the MBR-partition, which they almost certainly do, you're stuck with this misconfiguration until you can reformat, although they could look to the end of the allocated block. Luckily though OpenBSD doesn't actually care what the MBR-partition says when processing the disklabel, as you've noticed, so if you can't adjust MBR-partition 4 you can simply create MBR-partition 3 small enough that there's no overlap and pretend like nothing happened. How this came about is anyone's guess although OpenBSD's disc layout tools will definitely not have done this during a regular installation; luckily it doesn't actually matter though, it's just untidy. The net effect is simply that OpenBSD has been writing to disc blocks prior to the 'official' beginning of its MBR-partition. Writing to MBR-partition 3 will eventually also write to those same blocks if they are within its allocated area. Also are you sure you want to use type FAT12 and not FAT32? It also makes no practical difference (that I know of) but it's sloppy. Matthew [*] GPT is basically the same as MBR in its effect but unnecessarily bigger and more complicated and the differences are irrelevant here.
Re: Requesting vi tips
adr writes: > You see, is so easy to be an asshole. You're telling me? I know I'm not particularly active on OpenBSD's mailing lists but I've certainly been around. For the record, I have a finite amount of neurons with a correspondingly finite amount of synapses. There is only so much even I can hold in my head. Asking actual humans for access to the particular minutiae they happen to have itemised to the nth unnecessary degree for obscure factoids that might be found helpful is a valid strategy. Matthew
Re: On blindly running code
Raul Miller writes: > My mental model of computer security often approximates putting a bank > vault door on a picket fence (and maybe setting up a sniper to stop > people from climbing over the door). But in layers. One of them will work right? It's defense^Wobscurity in depth. > Doesn't mean that the exercises weren't worthwhile, but in my opinion > we put far too little effort into making people comprehend what's > going on. > (Not entirely true, and raspberry pi/arduino I think it's very true. Case in point is ssl/pkc. For a while I refused to believe that I understood public key cryptography because it was so incredibly simple and yet all the documentation I'd seen up to that point had been impenetrable, contradictory, incomplete or some mixture of the three. I can count on one hand the number of people I've worked with who understood it rather than relying on copy pasta. Hence LetsEncrypt now exists. The lack of understanding is tangible and worrying. > but I sometimes worry about the lack of > focus on physical and electronic abstraction layers.) Already lost. There's nothing real about an abstraction layer. We can't reconcile with them in the real world. Instead we ascribe human-like attributes to automota which can only mock the appearance without any of the substance. "Smart" devices are smart like a parrot that's learned how the crackers come and just as vindictive yet they have in less than half a generation become embedded into our lives and societies as though they are godlike in their prescience. They now drive our death machines around. We have machines with the intelligence of a parrot and the attention span of a toddler driving multi-tonne killing machines at upwards of 70mph. That's insane. Abstraction layers are all very well when developing algorithms but when the rubber hits the road the CPU's gonna do what the CPU's gonna do and if you don't know what it can, will and does do then no abstraction layer is going to help you. We need to trust the machines like the badly-treated rottweiler who's muzzle we can't remove and who's looking at our children hungrily, not like the adorable harmless puppies the devices try to act as and who's place they currently occupy. That is the fundamental flaw in our collective security model. I handle it by understanding the technology so I can work around the holes. Those who can't or won't need a better model than "aww! cute!" Anyway I didn't mean for this to turn into a rant so I'm done. Well I did because I started it as one but it was meant to be a rant about administrators and developers who don't understand what they're doing but do it anyway and not the sorry state of IT security around the world and how it's turning society into the worst possible bastard child of George Orwell and Aldous Huxley. That would require far more space than this mailing list allows to do it justice. > recovering backups (I've seen backup systems which never worked where A pile of data may look like a backup but without a proven recovery strategy it's just a pile of data. Matthew
Re: Requesting vi tips
Claudio Jeker writes:
> set wl=72 will limit the line lenght to around 72. Additionally you
> can use !fmt with movement chars to reformat sections. I use !{fmt
> or {!}fmt frequently to reformat the paragraph I'm in.
I didn't know [how] ! took movement commands. Thanks. I'll have a play
with that one.
It's not quite M-q (it's M not C) but I'm using vi after all.
Matthew
Re: Requesting vi tips
Raf Czlonka writes: > On Fri, Oct 18, 2019 at 03:12:37PM BST, cho...@jtan.com wrote: > Is this what you had in mind? > > set editor="EXINIT='set wraplen=72' /usr/bin/vi" I'm not sure that I'm happy with it doing it mid-insert. I'd prefer an explicit action or insert mode itself being adapted so that it includes a final reformat (ie. when I press escape (if the appropriate flag is enabled)). Also it has the fault that if, say, the 4th character of a word causes a line break, then reducing that word to less than 4 characters doesn't remove it (although the newline can be deleted as though it were inserted as usual, which is good). Matthew
Requesting vi tips
OK this has started to get on my nerves now. I use vi to enter emails despite using evil emacs for development and other general editing. Rather than linking them together (they're on seperate machines) to enter emails in emacs I'd rather figure out something interesting about vi. At the moment I limit lines to 72 characters through a laborious process of finding the appropriate space character myself and replacing it with a ^M. Obviously nonsense which is why I sometimes don't bother. (Sorry). I know about fmt and could easily concoct the pipeline to format each paragraph but I wonder if there's something that can correctly parse the whole email and format the entire thing en masse without me writing what would undoubtedly be Yet Another Poor Implementation. Alternatively is there something that would make vi do it on the fly, or something akin to emacs' C-q or vim's gq. Although I appreciate the fact that vi doesn't try to be clever. Thanks, Matthew
Re: On blindly running code
Frank Beuth writes: > On Fri, Oct 18, 2019 at 11:54:18AM +0100, cho...@jtan.com wrote: > >Virtualisation is not a panacea. I have managed to achieve data loss through > >destructi > ve actions taken within a "safe" virtualised sandbox. > > How did you manage that feat? Basically assuming "safe" then taking actions to subvert that, namely mounting an SMB share within the VM. rm(1) does not discriminate. My own fault obviously but it's notable that the "virtual environment == safe" assumption was shattered so effectively, so easily, and by actions which in most circumstances would be benign. That's not to even start on the fact that it's little more than process switching and virtual memory on steroids, so the extra seperation on top of what the OS already provides is little more than smoke and mirrors. > In the world of malware analysis, running code blindly (in a virtual > machine) in order to figure out what it does (by comparing "before" and > "after" snapshots) is standard operating procedure. > > (standard operating procedure doesn't necessarily make it a good idea, > but it is what it is) There's something to be said for it if your constraints are sound. I doubt a half-decent malware analyst isn't both extremely paranoid about their testing gig and still won't run code without at least a cursory glance at the disassembly. Consider that without access to the source code the game changes considerably. Matthew
Re: xauth segfault
Well it seems I was wrong and this is a common-or-garden bug. Specifically,
from xauth/gethost.c, starting at line 199:
#ifdef HAVE_STRLCPY
strlcpy(path, fulldpyname, sizeof(path));
#else
strncpy(path, fulldpyname, sizeof(path));
path[sizeof(path) - 1] = '\0';
#endif
if (0 == stat(path, )) {
is_path_to_socket = 1;
} else {
char *dot = strrchr(path, '.');
if (dot) {
*dot = '\0';
/* screen = atoi(dot + 1); */
if (0 == stat(path, )) {
is_path_to_socket = 1;
}
}
}
fulldpyname is "drogo.datum:0" and there is a directory in $HOME named "drogo".
is_path_to_socket then gets set to 1 and the strlcpy(buf, strrchr(fulldpyname,
'/') + 1, sizeof(buf)) a few lines down passes 0x01 as the source pointer to
strlcpy.
I don't know if it is or should be required that $DISPLAY pointing to a unix
socket can be a relative path, but if they must be absolute then this patch
enforces that (and fixes my segfault, though by making the same assumption that
$DISPLAY will include a '/' in two places).
Matthew
Index: parsedpy.c
===
RCS file: /home/flask/src/openbsd/cvsync/xenocara/app/xauth/parsedpy.c,v
retrieving revision 1.5
diff -u -p -r1.5 parsedpy.c
--- parsedpy.c 19 Feb 2017 17:30:58 - 1.5
+++ parsedpy.c 18 Oct 2019 12:02:34 -
@@ -177,7 +177,7 @@ parse_displayname (const char *displayna
#endif
if (0 == stat(path, )) {
family = FamilyLocal;
-} else {
+} else if (strrchr(path, '/') == path) { /* I'm not sure this is the
best way to test for this */
char *dot = strrchr(path, '.');
if (dot) {
*dot = '\0';
Re: On blindly running code
Shane Lazarus writes: > Heya > > My own experience agrees with you with regards to any system in production. > > However, it is also my experience that nothing demonstrates the > difference between what should happen and what actually occurs better > than running the code and seeing the aftermath. > > Thankfully, virtualisation makes things much simpler these days, and > running through everything on a clone prior to even considering steps > on the production system is consequently highly recommended. Virtualisation is not a panacea. I have managed to achieve data loss through destructive actions taken within a "safe" virtualised sandbox. If the only thing that can demonstrate what a piece of code does is to run it blindly, rather than to work it out by reading and study, then the code is faulty and should be replaced. I expect the code I use to be in this state before I will even begin to trust its documentation because if the developer doesn't understand what it does how can his explanation be at all enlightening? Executing code in a test environment should only be to *verify* the assumptions and calculations you have *already made*. A development, test or other environment is as much "in production" as any other, because if they somehow become unavailable then someone, somewhere is losing money. And if you took it down because you didn't know what code you were executing was going to do then it's your fault. Matthew
On blindly running code
With regards to recent discussion, here is a little anecdote that came out of the 6.5 to 6.6 upgrade. On one machine I run bitlbee, an IRC:IM gateway. After upgrading all the ports it left suggestions in the form of copy pasta commands to run to complete the upgrade process, as it does. One of these was rm -rf /var/bitlbee/*. Had I been so stupid as to just run the command, or if the hyper-complicated upgrade script required to support every possibility included a single mistake, all of the settings to connect to my IM accounts (currently constituting the only place some ancient passwords are guaranteed to be saved) would have been lost, where in fact what I had to do about those files was absolutely nothing. There is no fault here. The wording is something like 'you should also run', clearly not 'this is absolutely essential' (because if it was, why wasn't it done already or documented better?), which couldn't make it any clearer that you need to think first why you might want to run that command. There are good reasons not to delete user accounts when removing the software that uses them, for example, which is why pkg_delete doesn't but suggests that you might want to (with copy pasta for your convenience). It's my responsibility to understand the software I'm running, how it works and what effect the things I do will have on it. Nobody would have cried for me if I'd pasted first and only then realised that I'd lost everything. Take responsibility for your own computers or stop using them and buy one of those Fisher Price remote controlled radio-tracker remote execution vector iToys that all the kids are playing with these days. Matthew ps. I do have backups of course.
Re: xauth segfault
Klemens Nanni writes: > On Thu, Oct 17, 2019 at 10:30:54PM +0100, cho...@jtan.com wrote: > > I don't even know where to begin with this one > Start with providing a backtrace from the core dump: build xauth with > debug symbols and reproduce, then inspect with gdb. > > Otherwise you're on your own with this very special setup. OK I should probably make it clear that I figured that much out. I was unable to gleen much from it 6 months ago but didn't look hard because as I said it wasn't important enough to deal with as that machine doesn't really need X. It didn't just go away so this time I'm willing to put more effort in to figuring it out but before I attack the problem in earnest I'd like to gather some thoughts on why otherwise-identical VMs could be acting differently. I don't think this is a common-or-garden bug. (Also I finished upgrading things very close to the end of the day last night - there wasn't any time to test anything yesterday and I haven't yet had coffee today) Matthew
Re: auto_upgrade.conf et al man pages or documentation?
Chris Bennett writes: > On Fri, Oct 18, 2019 at 10:56:07AM +1300, Shane Lazarus wrote: > > > > So, I just ran sysupgrade with no options to see what would happen. That is the dumbest thing I've ever heard. Turn your computer in. You are incapable of handling one. > > If someone would be so kind as to point me in the right direction for how > > to prevent sysupgrade from being unsane, it would be much appreciated. The entire script is 208 widely-spaced-out lines of clear, simple shell. Including comments. Read the damn thing. Matthew
xauth segfault
This is sort of a weird one. Background is that I have a laptop with a bunch of VMs all running OpenBSD, now 6.6 (thanks!). The host runs X and one of the VMs runs the window manager which can then log into other VMs (or the host) to do whatever. My development environment, named void, is one those VMs. So far so strange. It's my setup and I like it. To run X apps, XAuthority credentials are banded about. All of the VMs have no problem with this except void, on which xauth segfaults. The login process when forwarding X credetials is essentially: var=$(xauth list $DISPLAY) ssh $remote xauth add $var ssh $remote DISPLAY=$DISPLAY $thing The strange thing is that with a few identical VMs running on this host, only on one of them does xauth segfault. All have today been upgraded to 6.6 and the fault was present on 6.5 too (I ignored it because I don't really need X there and hoped it would Just Go Away; it didn't). OpenBSD 6.6 (GENERIC) #353: Sat Oct 12 10:45:56 MDT 2019 [ksh]flask@chicken$ xauth list drogo.datum:0 MIT-MAGIC-COOKIE-1 86963dd9ee88bbfcc9eb66846b9cf4ce [ksh]flask@chicken$ ssh void OpenBSD 6.6 (GENERIC) #353: Sat Oct 12 10:45:56 MDT 2019 [ksh]flask@void$ xauth add drogo.datum:0 MIT-MAGIC-COOKIE-1 86963dd9ee88bbfcc9eb66846b9cf4ce /usr/X11R6/bin/xauth: file /home/flask/.Xauthority does not exist Segmentation fault (core dumped) [ksh]flask@void$ ^D [ksh]flask@chicken$ ssh shelob OpenBSD 6.6 (GENERIC) #353: Sat Oct 12 10:45:56 MDT 2019 [ksh]flask@shelob$ xauth add drogo.datum:0 MIT-MAGIC-COOKIE-1 86963dd9ee88bbfcc9eb66846b9cf4ce [ksh]flask@shelob$ I don't even know where to begin with this one (well I have some places to start looking but the fact that the otherwise-identical VMs react differently tells me this might be something deeper than the obvious so I'm waiting). I *think* this worked once but I can't be sure if I just didn't notice it failing. If nothing else I'll get around to figuring out how to build individual xenocara components and then step through the process to figure out what's broken in xauth but before I get to that I thought I'd see if anyone more familiar with these systems has any ideas. Matthew
Re: OpenBSD vmm
taylormlp writes: > Hello, > Is there plan to add graphics support to vmm/vmd? I'm sure there is. Matthew
Re: How can I remove sets installed by sysupgrade?
Paul de Weerd writes:
> On Tue, Sep 17, 2019 at 03:14:22PM +0200, Marc Espie wrote:
> | On Tue, Sep 17, 2019 at 01:48:19PM +0200, Paul de Weerd wrote:
> | > On Tue, Sep 17, 2019 at 01:27:23PM +0200, Marc Espie wrote:
> | > | > By having each set install a specific file in a well-known location.
> | > | > Before sysupgrade I wrote my own script to upgrade machines, this uses
> | > | > /var/db/sets/{base,comp,game,man,xbase,xfont,xserve,xshare} to
> | > | > determine what has been installed and upgrade only those sets.
> | > |
> | > | We actually know what file belongs to which set.
> | > | see /usr/lib/locate/src.db
> | >
> | > This doesn't list files from x-sets.
> |
> | ... there's obviously the corresponding database for x in xbase, duh
>
> Right. Wasn't aware of that one, but doesn't really make it easier:
>
> So, if /usr/lib/locate/src.db exists, we can ...
I rest my case.
Matthew
Re: How can I remove sets installed by sysupgrade?
Marc Espie writes: > On Tue, Sep 17, 2019 at 09:01:47AM +0100, cho...@jtan.com wrote: > > Marc Espie writes: > > > I'm a bit surprised nobody looked at instrumenting what sets are actually > > > installed on a machine during install/manual upgrade and cloning that > > > into sysupgrade to avoid this kind of surprise... > > > > I mentioned the possibility wrt. syspatch but it was rejected in favour > > of expecting users to run a default system or, in effect, become > > developers. Not a stance I entirely agree with but which nevertheless > > has its merits. > > But sysupgrade is a much "simpler" mechanism than syspatch. > > More importantly, > - sysupgrade is definitely about the sets > - if you have a non default installation, syspatch happens *at user level* > so you have every opportunity to figure out what's going on. > Where sysupgrade ? reboot the machine, see your disks overflow. Boom machine > kaput. The problem boils down to: how does sysupgrade, or any other tool, know which sets have been installed? That information is not tracked anywhere to the best of my knowledge. sysupgrade would have to determine which sets are installed either by heuristics, making its code much more complicated, or by being informed by the user, recursing back to the initial problem - perform maintainence who's actions differ depending on which sets are installed without the user being required to keep track of that set of sets. Or by abandoning an installation process as simple as 2½ steps. Don't get me wrong, I'd love it if those tools tracked sets such that they could be treated a little more like The Other Side handles the entire operating system as a set of packages, but it's not as simple a problem to solve as it initially appears, as if it ever is, which is why I didn't push the issue. Just see the plethora of package managers that exist. Matthew
Re: How can I remove sets installed by sysupgrade?
In particular, installing OpenBSD requires the following steps: 1) Partition and format the disc. 2) Untar a bunch of stuff (or in the case of /bsd*, copy). 3) Install the bootloader. That's _it_. The few other tasks performed by the installer, like installing /etc/hostname.*, KARL and configuring /etc/rc.conf.local, users, etc., are not at all necessary for a functioning *and future-proof*[*] system and can be entirely wrapped up in siteXX.tgz or install.sub's autoinstall.conf file. It would be nice to put more intelligence into the system maintainence tools to encapsulate some of the methods available for adapting that simple process, but a process as simple as that for performing a task as complex installing an entire operating system should not be given up lightly. Matthew [*] Useful is in the eye of the beholder.
Re: How can I remove sets installed by sysupgrade?
Marc Espie writes: > I'm a bit surprised nobody looked at instrumenting what sets are actually > installed on a machine during install/manual upgrade and cloning that > into sysupgrade to avoid this kind of surprise... I mentioned the possibility wrt. syspatch but it was rejected in favour of expecting users to run a default system or, in effect, become developers. Not a stance I entirely agree with but which nevertheless has its merits. Matthew
Re: How can I remove sets installed by sysupgrade?
Judah Kocher writes: > My router is headless. I have never run into an issue where I have > needed anything from the X sets Apparently you just did. > Therefore it seems like sound logic to not have those > bits and bytes present on the system so any > mis-configurations/bugs/vulnerabilities cannot impact my network security. This idea stems from sound advice but you are neglecting the parable of Chesterton's Fence[1]. > My router is not unbootable but I am not sure how secure it is anymore This says it all really. You should be, in spite of your present setback. You should not have set up your system in a way that permits you to be put in a position of not knowing how secure it is. Go back to first principles and redesign. > All of my partitions have at least 75% free space, except /usr which > after the sysupgrade is listed by df as being filled to 104% capacity. > I'm not even sure how that's possible. Because filesystems. They're documented. > I don't particularly look forward to having to rebuild it > from scratch or how long it will be before I find the time to do so. Good thing you have backups then, eh? > That being said, I realize there is plenty I do not know, First thing: A backup that cannot be [proven to be] restored is not a backup. > I experiment with making changes on a VM and observing the results until > I feel like I have a solid grasp on what will occur before pushing > anything to my live system, which sometimes takes months due to life, Good practice. > reading the sysupgrade manpage there is nothing > which even hints that any software which was explicitly rejected during > the original install will be installed anyway by this tool. *grumble* It seems that the OpenBSD devs and/or project "support" only an installation which has not not taken advantage of any of the optional non-extras (primarily: not installing sets) the installer has to offer. I understand and agree with the reasons for this but I grumble somewhat about the way it's presented. Passively-aggressive only because I have no solution on hand to fix problems I can't quite even describe. If your system is not a match then on your own head be it. It's a big, complicated thing but it's not that hard to understand. I suggest reading the sources to the boot loader, installer and the kernel's main startup routine to get a solid handle on things before progressing onto what /etc/rc and pals are doing and the layout of the filesystem etc.. > It looks like my best chance to be certain I have the router in the > state I think I do will be to do a fresh install and then use sysupgrade > using a variation of the script Leo mentioned in his email on 7/9/19: Or just store some bits in a place where they can't possibly be used so that you don't have to waste any of your limited effort on something that has no impact on anything? Your emphasis on security is admirable but misguided. Matthew [1] https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_fence
Re: How can I remove sets installed by sysupgrade?
Marcus MERIGHI writes: > please do *not* copy/paste/run this command! > something along these lines for the sets you did not want: > > $ ftp -MVo- $( tzf - | xargs rm > > you are aware that it is recommended to run with all sets? Despite previous posts requesting assistance with not doing so, I second this recommendation to anyone not able to construct that ftp/tar/rm command from first principles (and with a clear need to do so). Patronisation aside, your computer's storage is a lot cheaper than the mental effort required to deal with a system that's non-standard but only by having a few bits wasted by their _complete lack of use_. FilesystemUsedMounted on The system proper is tiny: /dev/sd0a 148M/ /dev/sd0e 860M/usr /dev/sd0h 203M/usr/X11R6 /dev/sd0g70.9M/var The user/development environment is little bigger: /dev/sd0i 4.7G/usr/local /dev/sd0m 1.1G/usr/obj /dev/sd0l 685M/usr/ports /dev/sd0j 1.0G/usr/src /dev/sd0k 688M/usr/xenocara /dev/sd0n 2.0K/usr/xobj Putting part-built binaries and /usr/local aside, that's only 1.2GB. 4.7GB is large for /usr/local but that's because this is my "throw everything at it" system. Even with this fully-packed system and the full source code the total is just a shade over 8GB. Despite space earmarked for growth it's difficult to stretch the base system to 16GB. I don't know about anyone else but I can't even find storage media that small any more. I'm all for minimising waste but effort where it's due. But see also https://twitter.com/rob_pike/status/966896123548872705 Matthew ps. FWIW where my systems were concerned I was looking at minimising waste through repetition of many VMs but there are other, in ways better, methods of doing that. Any which involve me thinking about it have a priori failed. pps. Reinstalling is not actually that big a deal. Partition, install boot sector, extract sets, install packages and finally site-specific files to /etc, /home, /var and possibly /srv or something. The installer can be easily configured to do all of this without human interaction prior to the first live boot.
Re: KARL sometimes renderring computer unbootable
Sebastian Benoit writes: > You dont say, but you are probably using 6.5? I am and that's a good point that I didn't think to consider, thank-you. > In current and thus in 6.6 the relevant line reads > > newinstall: > install -F -m 700 bsd /bsd && sha256 -h /var/db/kernel.SHA256 /bsd Problem solved before I got around to it. Again... Matthew
KARL sometimes renderring computer unbootable
Occasionally after a power loss some computers, especially virtual machines for obvious reasons, are no longer able to boot. The bootloader reads the kernel, one of the two spins for a bit and then the computer returns to the bootloader prompt. In the case of VMs, vmd eventually gives up and turns it off. After getting into an affected OS, /bsd doesn't match the sha in /var. The repair is easy thanks to the simple design - load bsd.booted into single user mode and replace /bsd (and the sha in /var) with it then boot as normal, taking care to let KARL finish this time. Obviously "don't keep losing power" is another solution, as is "get rid of the cats who keep knocking over the router", but neither is really workable and only hide the error anyway. The problem stems from here I think: newinstall: umask 077 && cp bsd /nbsd && mv /nbsd /bsd && \ sha256 -h /var/db/kernel.SHA256 /bsd I guess, and it is only a guess, that what's happening is that the filesystem doesn't finish writing /nbsd's data even after it's been moved to /bsd, so on my computers here I've put 'sync' between the cp and the mv to see if it resolves it (it will go away of course when 6.6 is installed) and I'll try to find the time to reproduce the problem reliably and hopefully produce a fix that's not essentially shotgun-debugging. In the meantime does that sound like a likely source of the problem, and if so is there a better way to fix it? Matthew
Re: Oddity re. order of ifconfig commands
Roderick writes: > > On Sun, 14 Jul 2019, cho...@jtan.com wrote: > > > I also string a cable between their ethernet ports for maximum speed > > Was it a crossover cable? I have no idea how long it's been since I had to care. I *did* mention that the physical setup already worked and was subsequently made to work. There is zero chance of hardware being at issue (almost -ed). > > drogo# pkill -f re0 > > Do you have somewhere a program called re0 running?! 43832 dhclient: re0 76984 dhclient: re0 [priv] > > drogo# ifconfig re0 10.100.200.1/24 > > Why the name of a whole net for just an address of an interface? I don't know what this means. How else should I give an ethernet device which otherwise has no network configured at all a full address? Todd C. Miller writes: > On Sun, 14 Jul 2019 12:35:32 +0300, cho...@jtan.com wrote: > > drogo# pkill -f re0 > > I'm assuming this is to kill off any dhclient for re0? Indeed. It's a laptop so it's sanest to have all devices try dhcp so I can usually just plug in and have things work. The 3-odd seconds extra boot time is irrelevant. > > drogo# ifconfig re0 10.100.200.1/24 # oops forgot up > > drogo# ping 10.100.200.2 > > PING 10.100.200.2 (10.100.200.2): 56 data bytes > > ping: sendmsg: Host is down > > ping: wrote 10.100.200.2 64 chars, ret=-1 > > I'm not sure what you are tying to do here. You haven't configured > re0 with an IP address. I suspect you really wanted to run "dhclient > re0" instead. The problem is that the line should have included 'up', as it did later on when the correct process was followed start to finish. I don't know what you mean by "haven't configured re0 with an IP address". What else is 10.100.200.1/24? Why does the absense of up in that command screw up that attempt and subsequent attempts (see my original post for the full transcript), and is there a less crude recovery mechanism than sh /etc/netstart? Matthew
Re: Oddity re. order of ifconfig commands
U'll Be King of the Stars writes: > On 14/07/2019 10:35, cho...@jtan.com wrote: > > I also string a cable between their ethernet ports for maximum speed which > > I bring up > manually at each and because I'm too lazy to automate it, that's > 10.100.200.2/24 on li > nux and 10.200.200.1/24 on openbsd. > > Is there documentation that explains how to configure this kind of > point-to-point Ethernet connection, and associated routing tables, on > OpenBSD? There's nothing to it really. If there are no other network connections up (ignoring lo0) then doing this on one machine: # ifconfig re0 up a.b.c.1/24 and this on another: # ifconfig re0 up a.b.c.2/24 Will, if they are on the same ethernet segment (as, for example, when they're both connected to the same switch or directly with a crossover cable*), and considering any firewalls present en route, allow them to communicate with one another on the configured address. Of course each re0 should be changed to the appropriate device name on the machine, and a, b and c must be chosen so as not to conflict with any other address that may be present on existing network devices (or networks they route to, such as the internet). Matthew [*] Or, if you have a machine made after the stone age with autosensing ethernet hardware, any cable.
Oddity re. order of ifconfig commands
I have two laptops, both on the same wifi network, one with linux and one with
openbsd.
I also string a cable between their ethernet ports for maximum speed which I
bring up manually at each and because I'm too lazy to automate it, that's
10.100.200.2/24 on linux and 10.200.200.1/24 on openbsd.
With the other side working fine (I'd detached my openbsd laptop to take it out
and reattached it later) I attempted to bring up the ethernet but got the
commands wrong, and this ensued:
drogo# pkill -f re0
drogo# ifconfig re0 10.100.200.1/24 # oops forgot up
drogo# ping 10.100.200.2
PING 10.100.200.2 (10.100.200.2): 56 data bytes
ping: sendmsg: Host is down
ping: wrote 10.100.200.2 64 chars, ret=-1
^C
Then:
drogo# ifconfig re0 up
drogo# ping 10.100.200.2
PING 10.100.200.2 (10.100.200.2): 56 data bytes
ping: sendmsg: Host is down
Forgot the IP I gave it? In that case:
drogo# ifconfig re0 10.100.200.1/24
drogo# ping 10.100.200.2
PING 10.100.200.2 (10.100.200.2): 56 data bytes
^C ## No 'Host is down' but maybe I was impatient.
Then even putting them together all in one as I should have originally
(ifconfig re0 up 10.100.200.1/24) had the same "Host down" result so I tried to
put it back to normal:
drogo# ifconfig re0 down
drogo# ifconfig re0 up 10.100.200.1/24
drogo# ping 10.100.200.2
PING 10.100.200.2 (10.100.200.2): 56 data bytes
^C
--- 10.100.200.2 ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss
Finally to just get it to work I reset the whole stack and did it the way I
should have originally:
drogo# sh /etc/netstart
re0: no lease.. sleeping
rum0: bound to 192.168.1.23 from 192.168.1.1 (84:be:52:c8:b8:52)
drogo# pkill -f re0
drogo# ifconfig re0 up 10.100.200.1/24
drogo# ping 10.100.200.2
PING 10.100.200.2 (10.100.200.2): 56 data bytes
64 bytes from 10.100.200.2: icmp_seq=0 ttl=64 time=0.767 ms
So everything's fine in the end but why did my mismatched commands above not
work although it seems like the result, ultimately, should be the same?
My /etc/hostname.{rum,re}0 files just contain 'dhcp' and, in the case of rum0,
a list of join instructions.
Matthew
Re: Postscript printer recommendations
Jonathan Drews writes: > > I am not sure why you want to avoid CUPS. Not a terrible propsal because it is a bloated piece of crap, but on the other hand it must interface with the satanc devices we call printers so concessions must perhaps be made. > fundamentals. That begs the question as to why a desktop user would > use a complicated system like OpenBSD. Short answer: Generally, don't. OpenBSD is not designed for users. They might (and frequently do) get some mileage out of it but when something goes wrong they're in the same place as the rest of us: on their own. > I never could get CUPS working in previous versions of OpenBSD. I'm afraid I've never tried because I just gave up on printing. Paying 10p per sheet to do it around the corner is easier, cheaper and puts my sanity at less risk (but librarians, man...). On the few occasions when cups has been the answer, I've spun up or found somewhere a linux box/VM and used that. God knows what it's doing underneath as I mash my way through the clicky gui but I can just print the dozen or so sheets I need and nuke the entire thing without having to care about such trivial concerns as security or long-term reliability. Good luck. > Also, IIRC CUPS requires chown and chmod to certain /dev files. I am > loathe to do that. I really don't want to mess with root file > permissions. IMHO, if you need a service, then add your account to > the appropriate group in /etc/groups. This is almost certainly possible and has already been arranged for. > According to Xerox's web page on Postscript, they claim that > Postscript gives higher quality renderings: > > "Unlike PCL, PostScript is device independent. This means that the > PostScript language creates all of the print data and does not rely > on the printer for print data. This allow the output to be > consistent when printed on more than one type of printer or print > device. Specifically, the graphic objects will be consistent and in > some cases of higher quality than PCL." This is misleading at best. PCL may be device-dependent but it's never used until the device is known and only for the final communication with that device. Whether it and your computer use PCL as a private protocol to convey part-processed postscript is a largely irrelevant cost-saving method introduced by printer manufacturers so that they don't need to implement a full-blown (turing-complete) postscript interpreter in what these days is disposable hardware. Their last sentence is as close as you can get to an outright lie without actually lying. As mentioned elsewhere, postscript is just a programme which is interpreted by a software running on a CPU to produce a raster image. What does it matter whether it's done by your computer's CPU or the printer's? Matthew
Re: Did I install correctly the openbsd?
SOUL_OF_ROOT 55 writes: > weak attempts to bait an argument Your trolling is both transparent and dull. The new system is clearly fine. Not only is your environment not in any way exceptional but it told you so at the end. Past evidence suggests that you're at least not entirely clueless so the only way you could misunderstand the message the computer told you is wilfully. Ergo, troll. For my part I'm starving you out unless you become useful. And no I'm not watching some stupid video which purports to teach me how to run a straightforward download-and-untar script. Matthew
Re: When will OpenBSD become a friendly place for bug reporters?
Perhaps rather than whining that OpenBSD lacks some specific feature, those who want it could write it? A novel idea, I know, but it IS specifically a development platform and there are precisely zero restrictions. Or if you don't wish to start with code, at least try a tack such as "I intend to write feature $foo and would like advice for how to go about it". Notice that the act of _writing actual code_ is still implied. I imagine that if a patch came through which adapted the build/release process such that symbols weren't removed but extracted into their own set for post-hoc installation by interested individuals, for example, that it would at least receive discussion if not eventual inclusion. The bitching and public masturbation in this and the recent X thread, among many other examples, helps no-one. Matthew
Re: ed(1) man page doesn't mention use of single / and ?
ropers writes: > Okay, so since nobody else appears to be making any pertinent noise, I > guess it falls to me: > > Index: ed.1 > === > RCS file: /cvs/src/bin/ed/ed.1,v > retrieving revision 1.70 > diff -u -r1.70 ed.1 > --- ed.1 26 Apr 2018 12:18:54 - 1.70 > +++ ed.1 6 Jul 2019 21:20:15 - > @@ -269,6 +269,9 @@ > current line, if necessary. > .Qq // > repeats the last search. > +The second slash is optional for a bare search without any suffixed > command, i.e.\& > +.Qq / Ns Ar re > +is sufficient when followed by a newline. > .It Pf ? Ar re ? > The previous line containing the regular expression > .Ar re . > @@ -276,6 +279,9 @@ > current line, if necessary. > .Qq ?? > repeats the last search. > +The second question mark is optional for a bare search without any > suffixed command, i.e.\& > +.Ns Qq ? Ns Ar re > +is sufficient when followed by a newline. > .It \&' Ns Ar lc > The line previously marked by a > .Ic k > > Questions? Comments? Complaints? Secondary trade sanctions? Better to be thorough, if this is to be done. The final slash in a substitution is also unnecessary and ed reacts differently depending whether or not it's included. I expect it's the same for the other commands with delimited options. Matthew
Re: OT: hardware war with manufacturers (espionage claims)
ropers writes: > ::I put on my robe and tinfoil hat.:: > ... Wow. The things you guys come up with ... I mean yeah, I guess, in theory maybe? Of course in order to achieve this level of evil you need highly competent governments and corporations but that's no problem right? Matthew
Bypass doas password check with chroot
This isn't a bug per se, more of an incongruity in how security-centric tools work wrt root, specifically doas and chroot/su/other: joe@drogo$ doas -s drogo# doas -u chohag -s doas (root@drogo) password: doas: Authorization failed drogo# chroot -u chohag / drogo$ ^D drogo# su -l chohag drogo$ ^D Obviously a little one-liner or tiny C app could achieve the same result too. I assume this is more or less known, since each tool is working to its designed spec, so is the above ultimately the desired behaviour? Should doas ask even for root's password while myriad other ways of obtaining any user ID do and probably always will exist? On some servers root doesn't have a password. Matthew
Re: Future of X.org?
li...@wrant.com writes: > Tue, 02 Jul 2019 08:40:35 +0300 cho...@jtan.com > > > > Also I don't need to fix your email system's inability to classify spam. > > YOUR mail server reputation is negative, fix your setup.. STOP spamming. IWFM Matthew ps. Two dots *and* two spaces? Try harder.
Re: Future of X.org?
li...@wrant.com writes: > You're misreading something, or talking to yourself, making corrections. > Your emails ended up in the spam twice so far, do something about that.. Two dots again? We've been over this. > Your emails came in as spam twice so far, maybe do something about that? Get it together. It's just counting. Also I don't need to fix your email system's inability to classify spam. Matthew
Re: Future of X.org?
li...@wrant.com writes: > Mon, 01 Jul 2019 07:09:41 +0300 cho...@jtan.com > > > > I don't think I'll be relying on software from such confused individuals > > any time soo > n. > > Since when? Make a note: your long lines will never fit on a punch card. I haven't used a punch card since ... well ever. I have my limits but they're not 72. Matthew ps. Yes, I did that on purpose.
Re: Future of X.org?
Ingo Schwarze writes: > the voice of reason. Listen to it. Matthew
Re: Future of X.org?
Juan Francisco Cantero Hurtado writes: > Can you show me what missing Wayland part is bigger than DRM+Mesa+LLVM?. Probably, but that's not my problem. > After the personal attack, I was hoping a more elaborated answer. There was no personal attack. That you feel there was reveals little more than the fragile state of your ego. Wayland adds little or nothing of value while changing everything. The Wayland crowd have the bigger point to prove. The onus is on them to prove that there's a problem, not on the people who have been working successfully for 3 decades to prove that there isn't. Matthew
Re: Future of X.org?
li...@wrant.com writes: > You can't do without YOU understanding basics of X11, do something else.. > Juan, I don't trust your lack of any qualification for even feature bait. Two dots? This thing should never have more than one dot. How about: > You can't do without YOUR understanding X11 basics; go do something else. Slightly awkward but still gramatically correct. Matthew
Re: Future of X.org?
Roderick writes: > > > On Sun, 30 Jun 2019, Juan Francisco Cantero Hurtado wrote: > > > You can run (local or remote) X11 applications inside of a Wayland > > compositor. > > The following contradicts your above assertion: > > https://wayland.freedesktop.org/faq.html#heading_toc_j_8 Wayland. The software product brought to you by the people with a FAQ containing this answer: To support remote rendering you need to define a rendering API, which is something I've been very careful to avoid doing. followed by this question: Why wasn't D-Bus used instead of the Wayland IPC mechanism? and then finally this answer: The alternative is to write a Wayland specific GL binding API, say, WaylandGL. I don't think I'll be relying on software from such confused individuals any time soon. Matthew
Re: Ansible install Re: Reboot and re-link
Frank Beuth writes: > You go ahead and continue to trust your VPS without taking any care to consider where your software comes from. It's choices like that which make "hardening" even be a thing. Have you considered _not_ building a system on a foundation made of cheese? Have fun with that. Matthew
Re: Ansible install Re: Reboot and re-link
Frank Beuth writes: > That's the interesting thing in my case (at least)... the system *IS* already > extant! And how have you introduced it to your command-and-control system? That is, ultimately, the key. > It has a nice shiny new Ubuntu/Debian/Fedora/centOS install that has just > been > imaged onto it using the hosting provider's default tooling, and SSH is > already > configured. (without blindly saying "yes" to the unexpected-fingerprint > prompt) That is what these tools depend on, but how is such a state of "already configured" achieved before the tool that does the configuration gets involved? This is why these are not the right tool for the job. > Normally in this situation one would just use Ansible to harden the default > Linux install and configure whatever applications are needed. But in this > case > I feel like hardening the Linux install even more, by replacing it with > OpenBSD > :) If you're hardening a system you've already lost. Systems should be hard by default. > Maybe I'm wrong, but it seems like if this problem were well-solved then it > would make easier to use OpenBSD in many more applications and situations. It's not well-solved because nobody tries to solve it. Installing systems in the first instance is assumed to be a manual process and no further thought is applied because you've got your clonable image, right? Actually that's not entirely true but I've yet to find a *portable* solution. > I'd love to see your tool. Oooh sir! > PXE is mostly not available for this case (in > general I am trying to target the most generic possible situation). PXE is only applicable in situations where the network can be guaranteed to be trusted; you're letting your DHCP server give you unverifiable code to execute and if you can't trust the network you can't trust the DHCP response. I wrote stash so that I could deploy my own servers without trust being an issue. It got as far as that and I (temporarily; I'll get back to it) lost interest. Nobody is paying me for this, I'm just bored. The documentation is ... poor. But it works. In my little network there are currently 6 distinct servers, all built using it with zero manual interaction. https://github.com/chohag/stash Enjoy. Happy to answer questions (I need some critical feedback). I plan to make more out of this but for the time being it's little more than a toy. Matthew
Re: Ansible install Re: Reboot and re-link
Frank Beuth writes: > Yes, and being able to Ansible-manage even the re-installation would make the > whole process that much nicer :) Ansible is not the correct tool for this job; it can only configure and maintain an _extant_ system. None of the recent plethora of configuration management tools have considered the scenario *before* an operating system has been installed. All of them expect the server to exist and for secured communication channels to have been established between it and the master control system before they are operable. The vast majory seem to solve this problem with the moral equivalent of blindly saying "yes" to ssh's unexpected-fingerprint prompt. If you wish to head down that rabbit-hole then best of luck to you. FWIW I'm working on-and-off on a tool which specifically automates *that* problem (build a new server/vm/chroot with zero human interaction so Ansible et al. can subsequently and safely take over) but what I've released so far is alpha quality at best. Conveniently if you're only targetting OpenBSD then it's entirely useless because, provided you can use PXE*, the OpenBSD developers have already solved it. Without Ansible. Matthew [*] The autoinstall/siteXX.tgz/etc. solution provided by the OpenBSD developers is very good but there are some questions I have around integrity on a potentially untrusted network. However as I'm trying to target more than just OpenBSD, and I don't trust any network, I've simply abandoned the idea of using PXE in my own environments so I haven't looked into the answers to them. YMMV.
Re: Ansible install Re: Reboot and re-link
Lyndon Nerenberg writes: > We are looking forward to that. *However*, there is a lot to be > said for regularly re-installing your hosts from scratch. This > ensures your installer scripts don't rot as host system "features" > accrete over time. This is prone to happen when you Ansible- or Or as I like to put it: Reboot* often, to ensure that you can. Uptime is overrated. Matthew [*] Or, as in this case, reinstall. It's more or less the same if you're set up right.
Re: Reboot and re-link (fwd) Maxim Bourmistrov: Re: Reboot and re-link
mathijs writes: > this makes misc@ so much more amusing I didn't join for the soap opera. Matthew
Re: The su manual doesn't mention use root account by default
Nan Xiao writes: > Hi Ingo, > > Thanks for your detailed explanation! Ingo seems to be rather good at those. The last trivial question I asked got an exposé on precisely how the ports and base development processes interact with one another. I propose a motion that every answer Igno makes to a question be turned into a FAQ item. Or, slightly more seriously, that response I got the other day on ports@ should be in a "how to do ports" document because wow, Ingo, you seem to have a knack for detailed (and *clear*) explanations and I don't think I thanked you for putting it all out there for me. Matthew
SOLUTION (with code), WAS: Re: When will be created a great desktop experience for OpenBSD?
Here is a script you can all use which selects a desktop environment,
installs it if necessary, and configures a (eg. your) user's X session
so that it starts when he, she or you log in, facilitating further
user-centric configuration.
Perhaps if you ask really nicely the devs will install it into the base
system somewhere for you and maintain the map of packages to
descriptions because even the densest among you must be aware by now
that you're never getting anything more complicated than this.
Now will you all please stop this and go and do something useful?
Matthew
src/gui-selector.sh:
#!/bin/ksh
default="fvwm"
builtin="cwm fvwm twm"
bloaty="kde gnome xfce"
gnome="gnome" # Is there something for this?
gnome_full=$gnome
gnome_bloat="gnome-extras"
gnome_bin=/usr/local/bin/gnome
kde="kde4-minimal"
kde_full="kde4"
kde_bloat="kde4-extras"
kde_bin=/usr/local/bin/kde4
xfce="xfce"
xfce_full="xfce-extras"
xfce_bloat=$xfce_full
xfce_bin=/usr/local/bin/xfce
cwm_desc="?"
fvwm_desc="Simple, effective, default"
twm_desc="Theo likes it so it must be good"
gnome_desc="We know what you want, except not correctly like Apple"
kde_desc="The only DE ever to kill my X server"
xfce_desc="I heard of this once"
error() {
if [[ $# != 0 ]]; then
echo "$@" >&2
else
cat >&2
fi
}
abort() {
error "$@"
exit 1
}
msg() {
if [[ $# != 0 ]]; then
echo "$@"
else
cat
fi
}
prompt() {
answer= # NOT local
echo -n "$@" ''
read answer
echo
}
root=
if [[ `id -u` -ne 0 ]]; then
root=doas
error < $userhome/.xsession
else
eval echo exec \$${de}_bin > $userhome/.xsession
fi || abort Could not write to $userhome/.xsession
msg << COMPLETE
$de has been installed and configured as $whose default desktop
environment. You may log out or reboot to enter it.
To install another environment and change $whose default, simply
run this script again.
COMPLETE
Re: single user question
Misc User writes: > It is theoretically possible to do that, but you'd have to do -a lot- > of work to get it to do so. It'd be much easier finding a proper > way to accomplish what you want without running single-user. I wouldn't recommend using single user mode to do anything other than repair but it's not true to say that doing so is a lot of work. /etc/rc is only ~600 lines and a lot of that is unnecessary if the server is going to run a single thing. In many cases you can probably get away with just mount/fsck/pfctl/netstart. There is actually no such thing as "single user mode". All there is is a kernel which hasn't done anything yet, and everything OpenBSD's does as it "enters multi-user mode" is described clearly and comprehensively in /etc/rc. Duplicating what little of it you want is, literally, as simple as copy-paste. Matthew
