Re: Disabling .core file generation
> You can do the same to avoid flat tires on my car -- just remove the > rubber. No more flats! But talking about cars.. Is it true that using only the extension of the rearview glass is all more safe?? :D -- Daniele Bonini Feb 21, 2023 21:34:02 Theo de Raadt : > You can do the same to avoid flat tires on my car -- just remove the > rubber. No more flats! > > Jonathan Thornburg wrote: > >> Another "low-tech" way of disabling .core file generation is to create >> the core file yourself, as a symlink to /dev/null: >> >> % ls -lFgd $HOME/*.core >> lrwxr-xr-x 1 jonathan jonathan 9 Feb 16 2022 >> /home/jonathan/WebKitWebProcess.core@ -> /dev/null >> lrwxr-xr-x 1 jonathan jonathan 9 Apr 23 2022 /home/jonathan/ctwm.core@ >> -> /dev/null >> lrwxr-xr-x 1 jonathan jonathan 9 Feb 16 2022 /home/jonathan/evince.core@ >> -> /dev/null >> lrwxr-xr-x 1 jonathan jonathan 9 Feb 16 2022 >> /home/jonathan/firefox.core@ -> /dev/null >> lrwxr-xr-x 1 jonathan jonathan 9 Feb 16 2022 >> /home/jonathan/iridium.core@ -> /dev/null >> lrwxr-xr-x 1 jonathan jonathan 9 Feb 16 2022 /home/jonathan/mutt.core@ >> -> /dev/null >> % >> >> This is a bit ugly, but it takes effect immediately and doesn't require root. >> >> -- >> -- "Jonathan Thornburg [remove -color to reply]" >> >> currently on the west coast of Canada >> "To report on BitCoin without mentioning the drug dealing and child abuse >> involved is like a history book describing the booming economies of the >> ante-bellum cotton states without mentioning that it was all built on >> slavery." -- Phill Hallem-Baker >>
Using scan_ffs to recover a disklabel
I broke my TV.
My TV is a monitor powered by a laptop running OpenBSD and in trying
to diagnose a problem which turned out to be in the NAS I managed to
fry the disklabel.
How?
Well, being unimportant the machine is also the guinea pig for
snapshot builds and other experiments so I thought I might try
removing the problem (thus confirming it's to do with running a
snapshot) by reverting to 7.2 stable.
I copied bsd.rd from a stable machine, booted into that and installed
over the top of the snapshot.
The install worked fine but nothing much ran and / filled up with
core dumps. Bummer.
Oh well, easy enough to fix, just move the system files out of the
way and reinstall. It's getting late but the OpenBSD installer's a
breeze and it should be all done and config files merged in 15
minutes.
Well it wasn't 15 minutes. I did the wrong thing and blasted the
disklabel.
The partitions weren't formatted. I knew this because I'd popped
into the installer's shell and replaced /sbin/newfs with an empty
file (what /bin/true used to be). The files were safe.
After stepping back and using another machine to get the music going
again I remembered that scan_ffs can find partitions when the
disklabel is lost. Using that I can either recover it in full, or
at least find /var with the backup.
Well the numbers scan_ffs gave me were gibberish. The manual warns
that it only looks for ffs1 partitions, not ffs2, but I ran it
anyway and tried poking variations on the numbers it gave me into
disklabel. That didn't work.
In the end I opened up scan_ffs.c to look at how it does its scan.
It proceeds in disk-block-sized chunks (512K) and applies each to
a 'struct fs' as defined in /usr/include/ufs/ffs/fs.h. Unfortunately
as the manual states it only considers ffs1 partitions, marked by
FS_MAGIC aka FS_UFS1_MAGIC. While there's a FS_UFS2_MAGIC printing
the location in which it was found didn't give me the result I
expected...
By this time, since I was figuring out scan_ffs and not looking for
my missing /var, I was running it over a small disk image where I
knew there was a partition at block 64, but the modifed scan_ffs
said the first partition was on block 192.
I thought that was strange but maybe there's a ffs1-like non-super-block
which points to the real ffs2 block later on. Hoping this was the
case I ran a scan over the whole disk printing each block that had
a FS_UFS2_MAGIC signature, offset by the amount to feed to disklabel.
Armed with a list of matching blocks (there were around 300 when I
stopped scanning after I was confident /var was found or missed) I
wrote a script to delete and recreate a partition beginning at each
potential block (the length doesn't matter) and try to mount it
(read only!). Since there were only a few blocks to check I scanned
the output by eye, found /var and copied the disklabel backup out
of it. With that it was a simple matter to restore the correct
disklabel, check the partitions and recover the system in full.
To obtain the list of blocks I added this clause after the main
test in scan_ffs.c:
else if (sb->fs_magic == FS_UFS2_MAGIC) {
printf("ufs2 @ %lld\n", (blk*512+n)/512 - 128);
This script fiddled with the disklabel to find a partition which
worked (this changes the real disklabel):
while read maybe; do
echo 'd d\na d\n'$maybe'\n\n\nw\n' | disklabel -E sd0
>/dev/null 2>&1
echo -n "$maybe: "
mount -r /dev/sd0d /mnt && ls /mnt /mnt/moved
umount /mnt 2>/dev/null
done
There are certainly better ways.
Restoring the disklabel is described in the manual:
disklabel -R sd0 /tmp/disklabel.sd0.current
The fully-integrated build system made testing changes to scan_ffs
a breeze even though my dev box is on the snapshot and the recovery
system was stable. Putting the snapshot back on the telly took much
less than 15 minutes.
It's possible scan_ffs could be simply extended to print potential
ffs2 partitions (there are a few more checks it could make to whittle
down the result) if the 128-block offset is constant across platforms.
Cheers,
Matthew
Re: Disabling .core file generation
You can do the same to avoid flat tires on my car -- just remove the rubber. No more flats! Jonathan Thornburg wrote: > Another "low-tech" way of disabling .core file generation is to create > the core file yourself, as a symlink to /dev/null: > > % ls -lFgd $HOME/*.core > lrwxr-xr-x 1 jonathan jonathan 9 Feb 16 2022 > /home/jonathan/WebKitWebProcess.core@ -> /dev/null > lrwxr-xr-x 1 jonathan jonathan 9 Apr 23 2022 /home/jonathan/ctwm.core@ -> > /dev/null > lrwxr-xr-x 1 jonathan jonathan 9 Feb 16 2022 /home/jonathan/evince.core@ > -> /dev/null > lrwxr-xr-x 1 jonathan jonathan 9 Feb 16 2022 /home/jonathan/firefox.core@ > -> /dev/null > lrwxr-xr-x 1 jonathan jonathan 9 Feb 16 2022 /home/jonathan/iridium.core@ > -> /dev/null > lrwxr-xr-x 1 jonathan jonathan 9 Feb 16 2022 /home/jonathan/mutt.core@ -> > /dev/null > % > > This is a bit ugly, but it takes effect immediately and doesn't require root. > > -- > -- "Jonathan Thornburg [remove -color to reply]" > >currently on the west coast of Canada > "To report on BitCoin without mentioning the drug dealing and child abuse > involved is like a history book describing the booming economies of the > ante-bellum cotton states without mentioning that it was all built on > slavery." -- Phill Hallem-Baker >
Re: Disabling .core file generation
Another "low-tech" way of disabling .core file generation is to create the core file yourself, as a symlink to /dev/null: % ls -lFgd $HOME/*.core lrwxr-xr-x 1 jonathan jonathan 9 Feb 16 2022 /home/jonathan/WebKitWebProcess.core@ -> /dev/null lrwxr-xr-x 1 jonathan jonathan 9 Apr 23 2022 /home/jonathan/ctwm.core@ -> /dev/null lrwxr-xr-x 1 jonathan jonathan 9 Feb 16 2022 /home/jonathan/evince.core@ -> /dev/null lrwxr-xr-x 1 jonathan jonathan 9 Feb 16 2022 /home/jonathan/firefox.core@ -> /dev/null lrwxr-xr-x 1 jonathan jonathan 9 Feb 16 2022 /home/jonathan/iridium.core@ -> /dev/null lrwxr-xr-x 1 jonathan jonathan 9 Feb 16 2022 /home/jonathan/mutt.core@ -> /dev/null % This is a bit ugly, but it takes effect immediately and doesn't require root. -- -- "Jonathan Thornburg [remove -color to reply]" currently on the west coast of Canada "To report on BitCoin without mentioning the drug dealing and child abuse involved is like a history book describing the booming economies of the ante-bellum cotton states without mentioning that it was all built on slavery." -- Phill Hallem-Baker
Re: pflow(4) and ipv6 flows
On 21/02/2023 14:41, Florian Obser wrote: > On 2023-02-21 14:24 +02, Kapetanakis Giannis > wrote: >> Yes I'm using default netflow version 5. >> >> is IPFIX better in general or the only one that supports ipv6? > Yes, version 5 is not specified for IPv6 flows, only IPFIX can export > IPv6 flows. Thanks, activated and already see them G
Re: pflow(4) and ipv6 flows
On 2023-02-21 14:24 +02, Kapetanakis Giannis wrote: > Yes I'm using default netflow version 5. > > is IPFIX better in general or the only one that supports ipv6? Yes, version 5 is not specified for IPv6 flows, only IPFIX can export IPv6 flows. > > thanks > > G -- In my defence, I have been left unsupervised.
Re: pflow(4) and ipv6 flows
Yes I'm using default netflow version 5. is IPFIX better in general or the only one that supports ipv6? thanks G On 21/02/2023 13:57, Florian Obser wrote: > Yes, > > wild guess, you are running with pflowproto 5. It probably works better > with pflowproto 10. > > On 2023-02-21 13:12 +02, Kapetanakis Giannis > wrote: >> Hi, >> >> Does pflow(4) support export of ipv6 flows? >> >> I see none recorded. >> >> Thanks, >> >> G >>
Re: pflow(4) and ipv6 flows
Yes, wild guess, you are running with pflowproto 5. It probably works better with pflowproto 10. On 2023-02-21 13:12 +02, Kapetanakis Giannis wrote: > Hi, > > Does pflow(4) support export of ipv6 flows? > > I see none recorded. > > Thanks, > > G > -- In my defence, I have been left unsupervised.
pflow(4) and ipv6 flows
Hi, Does pflow(4) support export of ipv6 flows? I see none recorded. Thanks, G
Re: Gitweb with Httpd on openbsd server
On 2023/02/19 18:17:25 +0100, airwan+...@mailo.com wrote:
> Hello,
>
> I am in trouble to set up gitweb with httpd. I am not aware with webersever.
First thing to notice is that most web server (httpd(8) from base but
also a few of the ones you can get from ports) on OpenBSD runs by
default in the /var/www chroot.
> My /etc.gitweb.conf contains:
>
> $projectroot = "/home/git";
so this is not going to work. A process inside the /var/www chroot
will try to open /var/www/home/git which I don't expect to exists.
Actually, the config file won't be parsed at all since it's in /etc...
> $projects_list = $projectroot;
>
> My /etc/httpd.conf contains
>
> server "default" {
> listen on * port 80
> fastcgi
> root "/gitweb"
> }
>
> because I copy /usr/local/share/gitweb to /var/www/gitweb
>
> The later contain gitweb.cgi.
>
> I also copy perl, and libraries to a subtree in /var/www/usr/...
Hold still for a moment and think what you're doing. You're almost
re-creating a standard OpenBSD installation inside /var/www. Why?
Some software just isn't designed to run in a chroot (gitweb in this
case) and forcing it to run inside one will always require hacks.
Lots of ugly hacks usually.
If you really really really _must_ use gitweb, then you'll probably
find it easier to run httpd(8) and slowcgi(8) without chroot.
Personally I won't do it. And neither suggest others to do so.
You're loosing many of the advantages the design and defaults of
httpd(8) and slowcgi(8) brings to you.
There are other solutions that can work nicely in a /var/www chroot
however.
For starters, there are various programs that exports a git repository
to a set of static HTML files (stagit comes to mind, but it's far from
being the only.)
cgit (as packaged on OpenBSD) should also work by default inside the
/var/www chroot and has an handy README with hints for the httpd(8)
configuration needed.
Then there's gotwebd, which I personally prefer among these options,
but note that I'm biased being one of the contributors ;-)
(and there's probably more I'm just forgetting about.)
