Re: Centralized logging

2021-04-25 Thread chohag writes:
> On 2021-04-24 22:50, 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.


Re: Full disk encryption including /boot, excluding bootloader?

2020-02-13 Thread chohag 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.



2020-01-16 Thread chohag
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

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.


Re: sysupgrade woes on beaglebone black

2020-01-10 Thread chohag
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.


Leaving OpenBSD (with patch)

2020-01-08 Thread chohag
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.


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?

2020-01-07 Thread chohag
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.


Keep up the good work (was: Re: But there is Fossil...)

2020-01-05 Thread chohag
Stuart Henderson writes:
> On 2020/01/05 00:33, wrote:
> > January 5, 2020 2:24 AM, "Roderick"  wrote:
> > 
> > > On Sun, 5 Jan 2020, 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.


Re: But there is Fossil...

2020-01-04 Thread chohag 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.

Read The Fucking FAQ


Re: What do you use to generate invoices on OpenBSD?

2019-12-22 Thread chohag
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.


Re: Re-organising partitions without re-installation

2019-12-22 Thread chohag
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.


Re: [sh] Single quote in comment withing subshell buggy

2019-12-14 Thread chohag
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

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.


--- 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;
+case '#':
+while ((c = getsc()) != '\0' && c != 

Re: cron output direct to mbox without smtpd?

2019-11-24 Thread chohag
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?


Re: sysupgrade to 6.6 failed at comp66.tgz

2019-11-23 Thread chohag
> 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:=/

Now you can, possibly, set SETS in the environent to override what
sysupgrade will even consider.


Re: Disabling laptop display & turning off suspend on lid close

2019-11-22 Thread chohag
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?


Re: sysupgrade to 6.6 failed at comp66.tgz

2019-11-22 Thread chohag
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.


Re: Modifying installXX.iso via script

2019-11-17 Thread chohag
Thomas Bohl writes:
> Am 17.11.2019 um 19:51 schrieb
> > 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.


Re: Modifying installXX.iso via script

2019-11-17 Thread chohag
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\
# -a  all-files
# -R  Rock Ridge
# -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

die_unsupported build/target combination

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.



Re: Boot failure on XPS 13/9380 (but bsd.rd works)

2019-11-17 Thread chohag
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.



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)

2019-11-17 Thread chohag
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
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.


OpenBSD 6.6 (RAMDISK_CD) #349: Sat Oct 12 11:03:52 MDT 2019
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
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: 256KB 64b/line 8-way L2 cache
cpu0: apic clock running at 24MHz
cpu0: mwait min=64, max=64, C-substates=, 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?

2019-11-15 Thread chohag
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:
> 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).


Re: Downgrade 6.6 to 6.5

2019-11-06 Thread chohag
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.


Re: What is the relationship between fdisk and disklabel?

2019-10-29 Thread chohag
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

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

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.


[*] 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

2019-10-18 Thread chohag
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.


Re: On blindly running code

2019-10-18 Thread chohag
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.


Re: Requesting vi tips

2019-10-18 Thread chohag
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.


Re: Requesting vi tips

2019-10-18 Thread chohag
Raf Czlonka writes:
> On Fri, Oct 18, 2019 at 03:12:37PM BST, 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

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).


Requesting vi tips

2019-10-18 Thread chohag
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.



Re: On blindly running code

2019-10-18 Thread chohag
Frank Beuth writes:
> On Fri, Oct 18, 2019 at 11:54:18AM +0100, 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 

Consider that without access to the source code the game changes considerably.


Re: xauth segfault

2019-10-18 Thread chohag
Well it seems I was wrong and this is a common-or-garden bug. Specifically, 
from xauth/gethost.c, starting at line 199:

strlcpy(path, fulldpyname, sizeof(path));
strncpy(path, fulldpyname, sizeof(path));
path[sizeof(path) - 1] = '\0';
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 

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).


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
 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

2019-10-18 Thread chohag
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.


On blindly running code

2019-10-18 Thread chohag
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.


ps. I do have backups of course.

Re: xauth segfault

2019-10-17 Thread chohag
Klemens Nanni writes:
> On Thu, Oct 17, 2019 at 10:30:54PM +0100, 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 


Re: auto_upgrade.conf et al man pages or documentation?

2019-10-17 Thread chohag
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.


xauth segfault

2019-10-17 Thread chohag
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  
  /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  

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.


Re: OpenBSD vmm

2019-10-12 Thread chohag
taylormlp writes:
> Hello,
> Is there plan to add graphics support to vmm/vmd?

I'm sure there is.


Re: How can I remove sets installed by sysupgrade?

2019-09-17 Thread chohag
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.


Re: How can I remove sets installed by sysupgrade?

2019-09-17 Thread chohag
Marc Espie writes:
> On Tue, Sep 17, 2019 at 09:01:47AM +0100, 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.


Re: How can I remove sets installed by sysupgrade?

2019-09-17 Thread chohag
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


[*] Useful is in the eye of the beholder.

Re: How can I remove sets installed by sysupgrade?

2019-09-17 Thread chohag
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.


Re: How can I remove sets installed by sysupgrade?

2019-09-15 Thread chohag
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.


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.



Re: How can I remove sets installed by sysupgrade?

2019-09-15 Thread chohag
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

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


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

2019-09-07 Thread chohag
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...


KARL sometimes renderring computer unbootable

2019-09-07 Thread chohag
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:

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?


Re: Oddity re. order of ifconfig commands

2019-07-14 Thread chohag
Roderick writes:
> On Sun, 14 Jul 2019, 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
> 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, 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 

> > drogo# ifconfig re0 # oops forgot up
> > drogo# ping
> > PING ( 56 data bytes
> > ping: sendmsg: Host is down
> > ping: wrote 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

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?


Re: Oddity re. order of ifconfig commands

2019-07-14 Thread chohag
U'll Be King of the Stars writes:
> On 14/07/2019 10:35, 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 
> on li
> nux and 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).


[*] Or, if you have a machine made after the stone age with autosensing 
ethernet hardware, any cable.

Oddity re. order of ifconfig commands

2019-07-14 Thread chohag
I have two laptops, both on the same wifi network, one with linux and one with 

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 on linux and 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 # oops forgot up
drogo# ping
PING ( 56 data bytes
ping: sendmsg: Host is down
ping: wrote 64 chars, ret=-1


drogo# ifconfig re0 up
drogo# ping
PING ( 56 data bytes
ping: sendmsg: Host is down

Forgot the IP I gave it? In that case:

drogo# ifconfig re0
drogo# ping
PING ( 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 had the same "Host down" result so I tried to 
put it back to normal:

drogo# ifconfig re0 down
drogo# ifconfig re0 up
drogo# ping
PING ( 56 data bytes
--- 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 from (84:be:52:c8:b8:52)
drogo# pkill -f re0
drogo# ifconfig re0 up
drogo# ping
PING ( 56 data bytes
64 bytes from 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.


Re: Postscript printer recommendations

2019-07-14 Thread chohag
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 

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?


Re: Did I install correctly the openbsd?

2019-07-11 Thread chohag
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.


Re: When will OpenBSD become a friendly place for bug reporters?

2019-07-09 Thread chohag
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.


Re: ed(1) man page doesn't mention use of single / and ?

2019-07-06 Thread chohag
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.


Re: OT: hardware war with manufacturers (espionage claims)

2019-07-03 Thread chohag
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?


Bypass doas password check with chroot

2019-07-02 Thread chohag
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.


Re: Future of

2019-07-02 Thread chohag writes:
> Tue, 02 Jul 2019 08:40:35 +0300
> >
> > 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.



ps. Two dots *and* two spaces? Try harder.

Re: Future of

2019-07-02 Thread chohag 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.


Re: Future of

2019-07-01 Thread chohag writes:
> Mon, 01 Jul 2019 07:09:41 +0300
> > 
> > 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.


ps. Yes, I did that on purpose.

Re: Future of

2019-07-01 Thread chohag
Ingo Schwarze writes:

> the voice of reason.

Listen to it.


Re: Future of

2019-07-01 Thread chohag
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.


Re: Future of

2019-07-01 Thread chohag 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.


Re: Future of

2019-06-30 Thread chohag
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:

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.


Re: Ansible install Re: Reboot and re-link

2019-06-23 Thread chohag
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.


Re: Ansible install Re: Reboot and re-link

2019-06-22 Thread chohag
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


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.


Re: Ansible install Re: Reboot and re-link

2019-06-22 Thread chohag
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.


[*] 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

2019-06-22 Thread chohag
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


[*] 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

2019-06-20 Thread chohag
mathijs writes:
> this makes misc@ so much more amusing

I didn't join for the soap opera.


Re: The su manual doesn't mention use root account by default

2019-06-13 Thread chohag
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.


SOLUTION (with code), WAS: Re: When will be created a great desktop experience for OpenBSD?

2019-05-23 Thread chohag
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?




builtin="cwm fvwm twm"
bloaty="kde gnome xfce"
gnome="gnome" # Is there something for this?

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
cat >&2

abort() {
  error "$@"
  exit 1

msg() {
  if [[ $# != 0 ]]; then
echo "$@"

prompt() {
  answer= # NOT local
  echo -n "$@" ''
  read answer

if [[ `id -u` -ne 0 ]]; then
  error < $userhome/.xsession
  eval echo exec \$${de}_bin > $userhome/.xsession
fi || abort Could not write to $userhome/.xsession

$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.


Re: single user question

2019-05-10 Thread chohag
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.


Re: Danish FreeBSD Developer hates jews collectively

2019-05-09 Thread chohag
Enji Cooper writes:
> Please leave this discussion on Twitter instead of flooding these mailing 
> lists. Linux/
> OpenBSD should not be exposed to this unnecessary drama, and FreeBSD-CURRENT 
> is the wro
> ng mailing list for this (try freebsd-chat@ if you are so inclined).

So you thought, why not spread it further?


Re: single user question

2019-05-09 Thread chohag
James Huddle writes:
> If the following questions trigger a sense of road rage, you may
> safely assume they are not directed to you.
> Is anyone running in single-user mode regularly?

I regularly boot things into single user mode to fix something or
otherwise engage in acts which could be confounded by running processes
holding resources open. I wouldn't say I regularly *run* in single-user
mode though.

> Is anyone running a web server, for instance, in single-user mode?

I am not and I can't see what the benefit could be - the kernel is
pretty good at process isolation. Assuming that you are asking because
you perceive benefits to doing so, I would be interested to know what
you think they are.

As you felt the need to begin with a defensive posture I shall end with
one; hopefully they will bookend that nonsense. This is not written in a
spirit of road rage but a spirit of enquiry.



Re: Upgrade procedure encrypted filesystem (6.4 -> 6.5)

2019-05-09 Thread chohag
shadrock uhuru writes:
> i've got a couple of follow up queries concerning post upgrade things todo.
> --- -dbus-1.12.10p0v0 ---
> Remember to update /etc/machine-id
> how do i update machine_id, i didn't find any man pages to explain ?

Ignore it. Nothing bad will happen. It's a linuxism.

> --- -libxml-2.9.8p0 ---
> Remember to update /var/db/xmlcatalog
> how do i update /var/db/xmlcatalog, found man xmlcatalog but mentions
> nothing about updating ?

Ignore it. Nothing bad will happen. Nothing done in XML ever mattered.

> --- -node-8.12.0 ---
> Error deleting directory /usr/local/lib/kde4/plugins: Directory not empty
> /usr/local/lib/kde4/plugins contains:
> ls /usr/local/lib/kde4/plugins
> accessible    imageformats  phonon_s_backend
> accessiblebridge  kauth script
> designer  kscreen   styles
> grantlee  marble
> gui_platform  phonon_platform
> should i go ahead and delete everything in the directory manually ?

Remove everything that is to do with KDE and go and quietly contemplate
the life choices which led to you having it installed in the first place.


Re: When will be created a great desktop experience for OpenBSD?

2019-05-08 Thread chohag
noah pugsley writes:
> Updated FVWM or a different default config?
> Sent from mobile.
>   Original Message  
> From: Christopher Turkel
> Sent: Wednesday, May 8, 2019 04:22
> Cc: OpenBSD Misc
> Subject: Re: When will be created a great desktop experience for OpenBSD?
> I'd like to see an updated FVWM as the default WM.

Then you'll need this:

Why is this thread still here?


Re: Activating second crypted (or other raid) device

2019-05-06 Thread chohag
trondd writes:
> On Sun, May 5, 2019 3:57 pm, wrote:
> > My goals are:
> >
> >   * /etc/rc already handles fsck of plaintext devices mentioned in
> > /etc/fstab.
> >   * /etc/rc already handles mount of plaintext devices mentioned in
> > /etc/fstab.
> >   * I would like to activate an encrypted/RAIDed device before /etc/rc
> > performs
> > either of those (so that code somebody else has written can do them
> > for me).
> >   * /etc/rc.local is called too late.
> >
> It's really not that big of a deal to call 'fsck' and 'mount' yourself in
> rc.local.

Sorry I guess I wasn't clear. I know I can use /etc/rc.local to do the
post-bioctl steps but that's boring; if I only wanted to get the
partition mounted I wouldn't have emailed. The idea here is to also fool
around with the system for shits and giggles to see if any new knowledge
falls out. It's my personal laptop, I know the risks and I can pick up
the pieces if it all falls apart.

I would like to to find way to fit my custom system into the same
subsystems and process that already exist to bring a standard system
up. I couldn't see anything in /etc/rc which would do this which is why
I customised mine but I would like to know if I've missed something in
there or if there's something elsewhere I don't know about that would
activate softraid volumes based on some configuration file.

If not then I also want to gauge thoughts on adding the ability bring up
softraid devices declaratively (and at the correct boot stage) similar
to how other devices are configured using eg. fstab, ttys, hostname.*.



Re: Activating second crypted (or other raid) device

2019-05-05 Thread chohag
Thomas Frohwein writes:
> On Sun, May 05, 2019 at 08:57:55PM +0300, wrote:
> [...]
> > Currently after every upgrade I patch /etc/rc to run /etc/rc.blockdev
> > (containing bioctl -cC -p /etc/sd0.key -l sd0a softraid0) before the
> > additional filesystems are checked or mounted.
> The order of sdX may change if e.g. a USB drive is plugged in during boot. You
> know you _can_ use the device UUID which AFAIK should be much more robust than
> using sdX. I used the following line at some point in an rc.local:
> bioctl -c C -l b3914b7ba0818788.a softraid0

I was unaware I could supply UUIDs to bioctl. Thanks.

I'm know of the danger of USB (and SD, etc.) insanity wrt device node
names. I simply make sure to never turn my laptop on with weird shit
plugged in to it. Seems like a safe bet.

> > Before I resign myself to patching /etc/rc in perpetuity, is there a
> > better or more canonical way to activate a second encrypted disc using a
> > key file in /etc before filesystems defined in /etc/fstab are checked or
> > mounted (it becomes /srv)?
> That would be rc.local. From rc(8):
>   Normally, rc.local contains commands and daemons that are not part of
>   the stock installation.

The problem with rc.local is that it's not executed until after fsck and
mount have parsed /etc/fstab (or /etc/fstab has been parsed for them;
whatever). If they do this before sd3 exists they at worst abort and at
best don't perform their desired function on the previously-encrypted
block device (ie. the plaintext block device is not scanned and mounted
automagically and my computer boots without a /srv).

> > The patch I use is below. Ignore the date; I've been using this since
> > around 6.2 at least. I feel rather silly saying that you're welcome to
> > use this tiny patch if it's useful, but there it is and you are.
> I empathize with your drive to get hands-on with the code to find a solution 
> to
> a problem and the desire to share it, but the solution you are proposing 
> should
> be discouraged. You are proposing a trivial 1-line patch to a file that isn't
> meant to be patched; ignoring the man page that contains a valid place for
> local customizations.

I completely understand why such a non-standard patch is
capital-W-Wrong. Developers and manglers believing otherwise are the
bane of my existance which is why I'm in NO wise suggesting this should
be immediately incorporated (perhaps I should have made that clearer in
the previous email - if you don't know how OpenBSD boots from init to rc
to getty then this patch is Not For You; it was included mainly so that
those who understood it would be able to skip my waffle and zoom in on
the actual question).

My goals are:

  * /etc/rc already handles fsck of plaintext devices mentioned in /etc/fstab.
  * /etc/rc already handles mount of plaintext devices mentioned in /etc/fstab.
  * I would like to activate an encrypted/RAIDed device before /etc/rc performs
either of those (so that code somebody else has written can do them for me).
  * /etc/rc.local is called too late.

Currently I achieve these goals with a simple (for me) patch on a single
machine's /etc/rc. I would love to hear of a better way or, if there
isn't one, try to come up with one that everybody can be happy with.

> For yourself, the closer you stay to the default install especially in regards
> to infrastructure like rc(8), the less likely you will run into bugs that are
> not reproducible by others.

I have no problem with deviating from the standard. I know what I'm
getting myself into and I know how to forge the pieces back together
again :)

I should probably come clean and point out that, having read
/install.sub and /etc/rc et al. inside, outwards and sideways, I'm
pretty sure that no such mechanism to mount RAID volumes prior to
fstab-parsing exists but if I'm wrong then please tell me. Alternatively
if there's any other interest than mine in creating one then I have
opinions and am happy to do the legwork, I only need a bit of a leg up
to make sure I remain within OpenBSD's coding guidelines etc..


'm not you're average noob,


Activating second crypted (or other raid) device

2019-05-05 Thread chohag
I have a laptop with two hard drives, a small fast ssd and a large slow
hdd (since replaced with a larger fast ssd). Both drives are encrypted
using bioctl. sd1 is the smaller boot device which becomes sd2, sd0 is
the larger device which becomes sd3. sd2 is activated before the kernel
by the bootloader after I successfully type in the password. sd3 is
activated during the boot phase using (only) a key in /etc/sd0.key.

Currently after every upgrade I patch /etc/rc to run /etc/rc.blockdev
(containing bioctl -cC -p /etc/sd0.key -l sd0a softraid0) before the
additional filesystems are checked or mounted.

Before I resign myself to patching /etc/rc in perpetuity, is there a
better or more canonical way to activate a second encrypted disc using a
key file in /etc before filesystems defined in /etc/fstab are checked or
mounted (it becomes /srv)?

The patch I use is below. Ignore the date; I've been using this since
around 6.2 at least. I feel rather silly saying that you're welcome to
use this tiny patch if it's useful, but there it is and you are.

Incidentally the real patch also also runs /etc/rc.early immediately
after rm -f /fastboot in order to move X to vt12 and open up vts 5 to
11 because I couldn't find any other way to hook into the boot process
early enough but I suspect I'm on my own with that one. (The command to
do that, if anyone's interested, is for c in 6 7 8 9 10 11; do wsconscfg
$c; done and you also need to update Xservers and ttys).


--- rc.orig Sun Jan  6 10:49:26 2019
+++ rc.mine Sun Jan  6 10:52:03 2019
@@ -353,6 +353,8 @@
exit 0

+[[ -f /etc/rc.blockdev ]] && sh /etc/rc.blockdev
 # Add swap block-devices.
 swapctl -A -t blk

Re: [6.5] Xfce: problem with shutdown menu

2019-04-28 Thread chohag
Theo de Raadt writes:
> "Stephane HUC \"PengouinBSD\""  wrote:
> > Hi, Tom. Ty for your reply.
> > 
> > On my file /etc/doas.conf, i've only one line, as:
> > 
> > "permit nopass setenv { ENV PS1 SSH_AUTH_SOCK } :wheel"

> So a javascript exploit in your browser can perform a rm -rf.

... everywhere.


Re: Code of Conduct location

2019-04-28 Thread chohag
Strahil Nikolov writes:
> Hello All,
> can someone point me to the link of the OpenBSD code of Conduct ?

I believe OpenBSD's code of conduct can be summed up as "if you are the
type of person who needs a code of conduct to teach to you how to human
then you are not welcome here".

At least I hope so.


Re: [website] Incorrect release date on the front page

2019-04-27 Thread chohag
Anonymous writes:
> Some pointless bullshit or other

Turns out time's not as simple a concept as your average developer assumed.

Apparently you're going to have to learn some things. It could be a first!

Welcome to the real world.

Good luck.


Re: Malloc config became global sysctl in 6.5

2019-04-27 Thread chohag
Otto Moerbeek writes:
> The mechanism is in the docs as well, not only in the code. You

You are of course correct, and OpenBSD has some of the best documentation
I've ever seen, but I've spent so long in linux land that whenever I'm
met with the question of how *exactly* something works, I just go straight
to the source. Source code can't lie (trusting trust notwithstanding).

> ignored my post about the symlink being confusing and error prone
> since the time it is read (before or after the chroot) is program
> dependent. It might even depend on options gives to a program when the
> first malloc call happens, making it even more unclear which symlink
> is being used.  Add the complexity with respect to unveil and pledge
> and it is clear why we replaced it. 

And I'm grateful. Having options - and such low-level options at
that! - encoded in such a weird way has always felt extremely
unopenbsd-like. This is another step toward sanity.

Simplicity! Thank you, devs.


Re: [website] Incorrect release date on the front page

2019-04-27 Thread chohag
Anonymous writes:
> Otto Moerbeek:
> > On Sat, Apr 27, 2019 at 03:13:00PM +, Anonymous wrote:
> > 
> >> Here too:
> > 
> > Does it matter? It is very common for publications to be dated in the
> > future. 
> > 
> > -Otto
> No, it's not common, neither for software releases nor for texts
> published online (blogposts, fiction, etc). Maybe you're talking about
> some niche. And yes, it matters because it's confusing: I opened the
> front page soon after the release but was in doubt whether it's for real
> because of the date.

Well I'm not an author, editor, publisher or printer but I'm fairly sure
nobody's ever gone from "I'm going to write a book" to "this book has been
printed and is already on the shelves" in less than 24 hours, so
publishing "in advance" like this makes total sense.

A bit weird but luckily I'm not a complete fucking moron so I'm able to
work out that when something says "released* on [future date]" that time
travel was not invented while I wasn't looking and that a week here or
there just doesn't matter.

People pointing out spelling mistakes have more utility than this thread.



[*] past tense

Re: Malloc config became global sysctl in 6.5

2019-04-27 Thread chohag
Igor Podlesny writes:
> On Sun, 28 Apr 2019 at 00:59,  wrote:
> [...]
> > >
> > > Oh, those hypocrite wankers here and there..
> >
> > If you actually read the code (I know, right? Who DOES that?) you'll see 
> > how omalloc_
> init perfectly embarrasses you. In 6.4 it would read the symlink, then 
> checked the envi
> ronment, and then consider the global variable malloc_options. In 6.5 it is 
> ... exactly
>  the same except that now sysctl is used instead of readlink (and hooray for 
> sanity).
> >
> > At no time was any attempt ever made by libc to force a programme to use 
> > only the set
> tings from sysctl née malloc.conf. If you had been using the environment 
> variable from 
> the beginning you would have been in _exactly_ the same position all that 
> time as you a
> re now. The security you think you've been relying on and have now lost was 
> never there
> . You have been protecting yourself with security theatre.
> >
> > Matthew
> Matthew, LOL, what?
> Read the code?
> You didn't even read the whole comment thread where I did explain that
> I was mostly concerned with cleared up environment other than changed
> options of that variable.

No, I did. I dismissed your arguments because they come from someone
who plainly has no idea what "the environment" even is.

malloc.c is quite lucid. Your continuing to spout off having clearly not
even glanced at it is a sorry state of affairs. But this is unix. We'll
continue to hand you as much rope as you like.

> Actually, I'd say that preparing chroots with malloc.conf as a symlink
> is more straightforward, more enforcing and easier to verify other
> than putting that as an environment option that would actually have to
> be read before target is running.

How in the ... Stay the hell away from my servers.

> And (of course) given with symlink
> it can't be so easily vanished when the whole environment is cleared
> up by user space.

/etc/malloc.conf can disappear exactly as easily as /etc/profile and
/etc/login.conf. More easily, in fact, if a tool to "handle" broken
symlinks gets involved.

> All-in-all, I didn't rely on this anyways.
> My question was purely theoretical and reaction was practically clumsy. :)

No, the reaction was dismissive of your complete lack of research and
understanding. Why should the developers or us other list members take
the time to read and understand the code you can't be arsed to?

In order to find out exactly how malloc handles its various
configuration sources took approximately 5 minutes of browsing on to find the appropriate function and I don't even
know C that well. Your unwillingness to do even that is why you're being
treated with such derision.

> Looks like decision made aren't subjects of discussing(?) Well, why
> the hell you have those mail lists then(?) :)

Building something as large as OpenBSD simply cannot be done without
discussion so this is either a poor quality attempt at derision or
some sort of delusion. In fact I imagine that intellient discussion is
restricted to places where the general public are not permitted so that
it remain intelligent - for which I am most grateful. It's quite clear
why you've not been invited.

tl;dr: You don't understand and your ranting is just turning you into a
spectacle. Please do continue; I have popcorn.


Re: Malloc config became global sysctl in 6.5

2019-04-27 Thread chohag
Igor Podlesny writes:
> On Sat, 27 Apr 2019 at 18:09, Marc Espie  wrote:
> >
> > On Sat, Apr 27, 2019 at 12:34:01PM +0700, Igor Podlesny wrote:
> > > On Sat, 27 Apr 2019 at 12:26, Sebastien Marie  wrote:
> > > > On Sat, Apr 27, 2019 at 12:17:21PM +0700, Igor Podlesny wrote:
> > > > > Previously users could have different behaviour of malloc 
> > > > > simultaneously: one i
> n
> > > > > global FS, others in chroots. Say, in global it could be more relaxed
> > > [...]
> > > > malloc(3) man page mentions several ways to set malloc options:
> > > >
> > > > - globally with vm.malloc_conf sysctl(2)
> > > > - externally per apps with environment variable MALLOC_OPTIONS
> > > > - internally per apps with global variable malloc_options in the program
> > > >
> > > > So I suppose you want to look at exported MALLOC_OPTIONS environment
> > > > variable.
> > >
> > > Wrong. Environment is easy to be changed by any non-privileged process.
> > > OTOH, root owned /etc/malloc.conf is not.
> >
> > Man, you have some really strange delusions about how to harden things.
> %  man malloc.conf | grep -i security
>  S   Enable all options suitable for security auditing.
> Oh, those hypocrite wankers here and there..

If you actually read the code (I know, right? Who DOES that?) you'll see how 
omalloc_init perfectly embarrasses you. In 6.4 it would read the symlink, then 
checked the environment, and then consider the global variable malloc_options. 
In 6.5 it is ... exactly the same except that now sysctl is used instead of 
readlink (and hooray for sanity).

At no time was any attempt ever made by libc to force a programme to use only 
the settings from sysctl née malloc.conf. If you had been using the environment 
variable from the beginning you would have been in _exactly_ the same position 
all that time as you are now. The security you think you've been relying on and 
have now lost was never there. You have been protecting yourself with security 


Re: Filesystem corruption with ext4 and qcow2 in vmm

2019-04-18 Thread chohag
Malte Wedel writes:
> Hello OpenBSD,
> I was trying to run Linux inside vmm, by converting an existing
> vmdk-image to qcow2 using qemu-img. While the configuration and setup
> seems to be straightforward, I had filesystem corruption issues on the
> ext4-fs inside the VM.

I would be more inclined to attribute this to an error in qemu-img, or
perhaps it's creating a version 3 image while vmm is compatible only
with 2 (I don't know either way).

> I am running OpenBSD 6.4. Are there known issues with qcow2 in vmm?
> Anything I can do to help understand/analyze the issue?

... however vmctl from -current, which is due any day now (judging from
changes on the website, perhaps imminently), can convert a raw image
into a (properly sparse) qcow2 file.


Re: How to make X listen tcp again?

2019-03-09 Thread chohag
Roderick writes:
> On Sat, 9 Mar 2019, wrote:
> > > Any hint?
> >
> > Yes: [...]
> Did you try it?

No but I think you missed the part where I said "and editing
/etc/X11/xenodm/Xservers" which is the where the server binary's options
(and server binary) are specified. For what it's worth I run a rather
unusual X configuration so I've had to dig into X' startup sequence
quite extensively.

I can't come up with any reason why the ability to listen on plain TCP
has been completely restricted, though if it has I can understand it
because having X listen on TCP is nuts[*], but if you want to customise
the X server which xenodm starts, eg. by allowing it to listen on
TCP, that will be the place to do it.

That said, I think the ssh -X solution is a lot more sensible.


[*] This doesn't stop me but in my case the X server runs on linux so
not applicable to your case.

Re: How to make X listen tcp again?

2019-03-09 Thread chohag
Roderick writes:
> The default changed, X does not receive Tcp connections. In FreeBSD
> I solved the problem with a file .xserverrc in my home directory
> with
> exec /usr/X11R6/bin/Xorg -listen tcp
> But this does not work with OpenBSD 6.4 (X does not even
> execute .xinitrc, I start X with xinit).
> Any hint?

Yes: you would be better off using xenodm and editing
/etc/X11/xenodm/Xservers, with a script and a doas config around 'rcctl
start xenodm' if you really must start it manually, but if you don't
want to do that for whatever poorly-considered reasons then xinit does
in fact use the xserver and xinit rc scripts provided they're not
overridden on the command line or in the environment:

 * if no server arguments given, check for a startup file and copy
 * that into the argument list
if (!server_given) {
char *cp;
Bool required = False;

xserverrcbuf[0] = '\0';
if ((cp = getenv("XSERVERRC")) != NULL) {
snprintf(xserverrcbuf, sizeof(xserverrcbuf), "%s", cp);
required = True;
} else if ((cp = getenv("HOME")) != NULL) {
snprintf(xserverrcbuf, sizeof(xserverrcbuf),
 "%s/%s", cp, XSERVERRC);


Also you're right: X does not execute .xinitrc. xinit does that.


Re: "bioctl -d" before shutdown

2019-02-25 Thread chohag
Roderick writes:
> I suspect, umount (that always syncs) is enough and umount
> happens always at shutdown.

How do people cope with "I suspect"? "I suspect" would scare the crap
out of me. Did it never occur that it's possible to _know_?

Not unmounting is dangerous because there are in-memory
buffers. Unmounting a filesystem syncs those buffers _to the physical
medium_. What is anyone afraid might happen after that(*)?

I'm a million miles from a kernel hacker but sheesh! It's not bloody
rocket science! Understand your tools before you use them.


[*] RAID and other hardware magic notwithstanding but if you're using
that then you know what you're doing and if you don't then you have my
ridicule. Give your soon-to-be-ex employer my contact details.

Re: Confusion re. VMs, bridges, intergace groups and pf.

2018-12-20 Thread chohag
Additionally, under which circumstances could/should I use interface
groups and under which rdomains? I cannot discern any practical
difference between them except in how they're labeled (numeric vs.
symbolic) although I confess that my experience with network routing
has been tainted by the Other OS so my knowledge is there murky.


Confusion re. VMs, bridges, intergace groups and pf.

2018-12-20 Thread chohag
Something in the documentation regarding VM network iterface groups is
unclear to me.

I have created a switch and VM in /etc/vm.conf:

  switch "private" {
interface bridge0
group private

  vm "test" {
memory 2G
disk /srv/vm/test.img
interface { switch "private" }

Which correctly creates a tap device with the group when started:

  tap0: flags=8943 mtu 1500
  lladdr fe:e1:ba:d9:26:d5
  description: vm4-if0-test
  index 15 priority 0 llprio 3
  groups: tap private
  status: active

The bridge is configured as:

  /etc/hostname.bridge0:add vether0

So far all well and good but attempting to craft pf rules to filter 'on
private' apparently has no effect.

This if my /etc/pf.conf (comments sanitised):

  set skip on lo

  match in all scrub (no-df random-id max-mss 1440)
  antispoof quick for { egress wlan }

  match log on private proto tcp

  # NAT everything else
  match out on egress inet from !(egress:network) to !self nat-to (egress)

  # Permit inbound ssh
  pass in quick proto tcp from any to self port ssh

  # Open everything during testing
  pass quick

Specifically, the match log line doesn't record anything (verified with
tcpdump -i pflog0) with 'on private' but does with 'on vether'. So how
can I filter based on the interface group to which a VM or switch is
assigned as vm.conf(5) claims I can (in VM CONFIGURATION/interface/group)?

Have I made a mistake in my configuration somewhere, misunderstood the
documentation and how to use interface groups, or is this a bug? I am
using a freshly-installed 6.4 on amd64.



Re: Automated remote install

2018-12-20 Thread chohag
Philipp Buehler writes:
> Am 20.12.2018 19:24 schrieb
> > I'm not sure what you mean by that. The script I posted the other day
> > is part of a (working, tested) process to create an openbsd image
> > within openbsd and then upload it to aws as an iam. I based it on, I
> > think, an earlier version of the instructions linked above. No linux
> > or osx required (no osx even present).
> News to me that vagrant and esp. virtualbox is available on OpenBSD.

Well obviously I didn't use those, they're shit. Which part of "based it on" 
wasn't clear? I used vmm and sh, which make the 'standing up a vm' part of the 
process so simple that the scripts which implement it barely deserve the name.


Re: Automated remote install

2018-12-20 Thread chohag
Philipp Buehler writes:
> Am 20.12.2018 18:13 schrieb David Diggles:
> > However it's possible to build for AWS.
> >
> and there's more stuff "in the pipe", since the above
> needs a Linux or OSX environment
> Next year ;) it'll be possible to do this on OpenBSD 
> (vmm/packer/vagrant).

I'm not sure what you mean by that. The script I posted the other day is part 
of a (working, tested) process to create an openbsd image within openbsd and 
then upload it to aws as an iam. I based it on, I think, an earlier version of 
the instructions linked above. No linux or osx required (no osx even present).


Re: Odp.: Automated remote install

2018-12-17 Thread chohag
Below is my work-in-progress code to take an openbsd cdXX.iso and inject the 
bare minimum necessary to autoinstall from a configuration file embedded in the 
image (it also reconfigures the console to run over the serial port - 
especially useful on a VM). There are no doubt better ways to do much of this 
but it's enough for me for the time being.

You will need an answers file. To automatically partition you will need to 
include this answer:

URL to autopartitioning template for disklabel = file:/disklabel.template



# TODO: Get version from "$iso"

eval size=\$size_"$scheme"
eval sets=\$sets_"$scheme"

# OpenBSD's partitioning will be performed by the installer

# Only this stuff needs root, and only because the cd is _mounted_:
root vnconfig $loop "$iso"
root mount -o ro /dev/${loop}a "$mount"
# Needs root because bsd.rd is 750
root rsync -a --delete --exclude=TRANS.TBL "$mount"/ "$where"/cd/
root chmod -R a+rwX "$where"/cd
root umount "$mount"
root vnconfig -u $loop

echo set tty com0 >> "$where"/cd/etc/boot.conf

elfrdsetroot -x "$where"/cd/$version/amd64/bsd.rd "$where"/ramdisk
root vnconfig $loop "$where"/ramdisk
root mount /dev/${loop}a "$mount"
root cp "$libimage"/installer.openbsd "$mount"/auto_install.conf # .type for 
sets? ed?
root ed -s "$mount"/auto_install.conf <" \
-V "OpenBSD/amd64   ${OSREV} boot-only CD"   \
-b ${OSREV}/amd64/cdbr -c ${OSREV}/amd64/boot.catalog\
rm -fr "$where"/cd "$where"/ramdisk &

  # Questions: At what point does KARL clean up the other kernel's files?
  # When to set proxy and where?
  # syspatch on first boot
  # Password must be 13 *s

Re: alix 2d13 + 6.4: should it work?

2018-11-21 Thread chohag
"Theo de Raadt" writes:
> First time you need to
> stty com0 
> set tty com0
> then you can boot.
> The installer will remember this for next time, but our kernel does not
> know the speed so early on.

Strictly speaking the installer _asks_ you if you would like it to remember
the setting for next time, which I find to be a nice touch as I may want to
install a server using the serial console but run it without one.


Re: identifying software and licenses used in base install

2018-01-18 Thread chohag
"Jake D. Parsons" writes:
> You seem to be railing against some perceived notion of injustice in

Injustice? No. Irrelevence.

> some perceived notion utopia. What is the point and agenda here? Why do

Utopia? Have you ever even *run* a computer system? My point is that I'm tired 
of the excessive waste and shere incompetence caused by bickering between 
people unwilling to humble themselves enough to admit to their shared 
experiences and common goals. How did we *ever* let the emperor's new server 
come to pass?

Although it does pay well.

> different technologies? Because it is their choice and considerations of
> what would work best for them. I' am glad there is so many choices. It

This sentence no verb. If I assume 'exist' it can only imply that you 
misunderstand. Quelle surprise.

The problem is not different technologies; competition builds strength. The 
problem is identical bikesheds painted different colours; competition can also 
end in a premature death of misdirected talent.

Ingo, although I disagree with the finer points of his argument, is the only 
person in this thread yet to talk sense. There's _so much_ posturing. And to 
what purpose?

> means the riff raff can float their raft over there and I can float my

Always it is "they" who are the riff-raff. Such arrogance.

> raft over here.

And yet they're still rafts, while we fool ourselves that we man a battleship.

Enjoy your lawyer-enriching disaster while you are ground into irrelevance 
beneath a mountain of impotence and wasted effort.


Re: identifying software and licenses used in base install

2018-01-17 Thread chohag
"Theo de Raadt" writes:
> > Is there, by chance, such a breakdown available for these already?
> No.  We did our best.

To be fair, these statements are potentially contradictory. If you (plural) 
only "did your best" (and what more could have been done?) then it is at least 
in *theory* possible that some mis-licensed piece of code slipped through.

In fact I expect this didn't happen, but regardless ...

> Always interesting that the more one works in the free software
> space, the more constraints get added by the public.
> Sometimes it is almost like there is a stream of people who want us
> to stop trying.
> And quit.   Some of you can see it, right?

... as more time goes by the more damage and less advantage I see by the 
existence of software licenses. I signed up to this life to be a programmer not 
a lawyer and over the years I've spent dealing in various parts of the computer 
ecosystem I've seen them causing more harm than good in practically every case.
 describes a sorry state of affairs. So much good technology has been lost, and 
so much potential for cooperation has been squandered, by schoolyard bickering 
between the ignorant over irrelevant (and I might add, euro/anglo-centric) 
ideas of propriety.

Why did BeOS and QNX, among many many others, dwindle into obscurity?

Why are zfs, jails, kvm, pf not integrated into every operating system?

Why are hardware drivers not developed centrally?

Why do we have half a dozen java (the write-once run no^H^Hanywhere language) 

Why did Debian waste some of our limited effort on a useless and disruptive 
fork of mozilla?

Why does mariadb even exist?


Et cetera.

Such a terrible waste. We have become divided at our own hand and are being 
slowly conquered, and who does it benefit? The public? Other programmers? The 
state of the art?


Re: OpenBSD !HTTPS websites - why?

2018-01-15 Thread chohag
"who one" writes:
> Hello, 
> When can we have HTTPS connection on these websites? 
> What website remains that doesn't have HTTPS yet and related to OpenBSD? 
> Security should be in layers, HTTPS is one additional layer. 
> 70% of the websites in the world uses HTTPS: , 
> see "Percentage 
> of Web Pages Loaded by Firefox Using HTTPS". If OpenBSD is security oriented, 
> HTTPS should be 
> de facto. 

What security does exposing's public websites over https grant? 
What threat model is doing so, with all the extra work and extra opportunities 
for failure, supposed to circumvent? Security is not a flag you can toggle on 
or off. The x509-based PKI is a racket which I, for one, am glad openbsd has 
not succumbed to.

This has been discussed ad nauseum.


Re: spam (was: re: code duplication)

2017-08-27 Thread chohag writes:
> Lesson: never configure a public machine to misbehave. People might be
> trying to get work done and take offense if they're stopped in that rude
> manner (just a huge delay, 'permission denied' and closing the connection
> would've IMO certainly sufficed).

Excuse me, I apologise to butt in on what clearly of great importance to
the future development of OpenBSD but I've not really been paying this
argument much attention and I want to clear something up.

Is this farce all because you're upset that a machine insulted you?


Trivial bug in installer's .profile

2017-06-03 Thread chohag
Job control is disabled prior to setting up the auto-install timeout. It
is then re-disabled when the timer has been started.

The second set +m should be set -m or be removed.

# Stop monitoring background processes to avoid printing
# job completion notices in interactive shell mode.  This
# doesn't stop the "[1] " on starting a job though;
# that's why re redirect stdout and stderr temporarily.
set +m
exec 3<&1 4<&2 >/dev/null 2>&1
(sleep 5; kill $$) &
exec 1<&3 2<&4 3<&- 4<&-
set +m


Re: Booting encrypted drive from another device

2016-06-20 Thread chohag
Bodie writes:
> access then you are screwed. It is just matter of your importance to
> attacker if it will be sooner or later.

You briefly touch on it here

> Attacks on CEO level mentioned in postthey have already laptop
> made in China and there is plenty of examples how HW is screwed up
> these days by firmware and other code doing all the crazy stuff where
> even best OS can not help to protect against

But then go and ignore it here.

There are threat levels between Johnny Nobody and NSA's Most
Wanted. While both attacks are eminently possible, attacking the
hardware or firmware is hard while attacking the bootloader is easy, if
for no other reason than by the time you get to the boot loader you
effectively have 1 possible architecture to deal with and plenty of
space in which to do it.

I've achieved with little fuss what was originally requested in this
thread on Linux and FreeBSD and I may or may not have done so using
OpenBSD. I forget whether I got it working or not - probably did as it's
reputedly possible and I do remember poring over OpenBSD's boot loader
code to find something out but I needed a hypervisor on the tin and
FreeBSD and Linux were the only options there.

So if it's easy to do and the inconvenience is acceptable, it provides
protection which is in some cases unnecessary and in some insufficient
but is neither in all.


Re: how to send email via Mail

2016-02-26 Thread chohag
Eric Furman writes:
> On Fri, Feb 26, 2016, at 09:22 AM, Артур Истомин wrote:
> > With this approach, we will have only one email provider. His name is
> > Google.
> > Spam and other black sides of today email system is price we pay for
> > decentralized system. And it's worth it.
> What Nick was trying to say was, "If you do not understand internet
> e-mail from end-to-end please do not run an e-mail server."
> ...
> An amateur running an e-mail server is MUCH more likely to become
> a SPAM bot. And, no it is not worth it.

While I agree that an amateur running an e-mail server is quite likely
to become a spam bot I'd nevertheless suggest that this possibility, and
even the spam the rest of us must deal with, is worth the price of email
being decentralised and not dictated by the likes of Google, Microsoft,
et al.

That said, I still don't recommend running one, amateur or
otherwise. Painful memories...


Re: Ntpd's confusing log messages

2016-02-07 Thread chohag
Christian Weisgerber writes:
> On 2016-02-06, Lampshade  wrote:
> > Feb  6 17:57:25 host ntpd[7585]: peer now valid
> > Feb  6 17:58:17 host ntpd[9279]: adjusting local clock by 9.096751s
> > Feb  6 18:02:02 host ntpd[9279]: adjusting local clock by 7.971861s
> > I don't think that clock is adjusted "by" that values.
> It is.

There is a difference between "how much the clock is adjusted by", which
is implied by "is adjusted by", and "how much the clock needs to be
adjusted by", which is what's being done.

The message is the best kind of correct but could be clearer by either
including the amount of adjustment occuring at the time the message is
logged or distinguishing between "the amount that the clock needs to be
adjusted" and "the amount that the clock is being adjusted by right
now", eg.

"adjusting local clock by ms out of s"

 - or -

"local clock s out of sync; skewed ms (forwards|backwards)"

Whether clarifying this message lies within the purview of openbsd ports
is another matter.


Re: No more proxy on ftp(1)?

2016-02-01 Thread chohag writes:
> Thank you for your help Stuart. I'll just use curl for now. Actually use
torsocks seems a bad practice for any situation, I should just set a
transparent proxy (but the pf.conf
> from does not work, I'll need to write is myself some day).
> Thanks again.

For the benefit of your lazy bone, and anyone else who comes across it,
here's the configuration I worked out. In OpenBSD's favour, I managed
this despite being relatively new to OpenBSD administration and
completely new to pf, so I don't know if it's 'right', but it is

Tor router sits on a lan as any other server would at and the
subnet it anonymises at route through it
(enforced by the switch/bridge they all plug in to).

# cat /etc/pf.conf

pass in quick inet proto tcp from to port tor

pass in quick inet proto udp from to port domain
pass in quick inet from divert-to port transtor
pass out quick inet from divert-reply
block in quick inet from

# getent services tor transtor
transtor   9040/tcp

# grep -v ^# /etc/tor/torrc | hand-grep _RELEVANT_LINES_
OutboundBindAddress # Bind to the lan for outgoing connections

SocksPolicy accept
SocksPolicy accept
SocksPolicy reject *

AutomapHostsOnResolve 1
TransProxyType pf-divert



  1   2   >