[history][humour] B before C (was: The su manual doesn't mention use root account by default)

[ropers]

Ingo Schwarze wrote:
> su(I) goes back all the way to v1: (...) It wasn't in v0 PDP-7 UNIX though:
> https://www.tuhs.org/Archive/Distributions/Research/McIlroy_v0/UnixEditionZero.txt

>From that text file's Introduction:

>> Besides the system proper, the major programs available under
>> UNIX are an assembler, a text editor based on QED, a symbolic
>> debugger for examining and patching faulty programs, and "B", a
>> higher level language resembling BCPL.

The then newly-invented B. :)
No, not C, B.

Ancestral note:

Machine code begat assembly; and assembly begat Speedcoding; and
Speedcoding begat Fortran and his brethren; and Fortran begat Algol
and his son.  And Algol the Younger begat CPL; and CPL begat BCPL; and
at the dawn of the Age of Unix, BCPL begat B, of whom was born C,
which is called with cc, and C sys-compilst.

(with apologies to Matthew the Evangelist)

Re: Core firefox, was: (Re: alc0 watchdog timeout)

[PengouinBSD]

I installed few days ago gdb:

(query is a personal alias for pkg_info -Q)
$ query gdb | grep installed
gdb-7.12.1p5 (installed)

$ gdb --version
GNU gdb 6.3

If I try with egdb:

$ egdb /usr/local/bin/firefox
firefox.core
   

GNU gdb (GDB) 7.12.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-openbsd6.5".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/local/bin/firefox...(no debugging symbols
found)...done.

warning: Couldn't find general-purpose registers in core file.

warning: Couldn't find general-purpose registers in core file.
#0   in ?? ()
(gdb) bt
#0   in ?? ()
Backtrace stopped: not enough registers or memory available to unwind
further
(gdb) thread 1
[Switching to thread 1 (process 1)]
#0   in ?? ()
(gdb) thread 2
Unknown thread 2.
(gdb) thread 0
Invalid thread ID: 0
(gdb) q

No help more! :(


On 6/26/19 9:37 PM, Todd Mortimer wrote:
> Hmm. That’s obviously not very helpful. 
>
> Perhaps try ports gdb? It will install as egdb. 
>
>> On Jun 26, 2019, at 21:33, Stéphane HUC PengouinBSD  
>> wrote:
>>
>>> On 6/22/19 5:32 PM, Todd Mortimer wrote:
>>> On Sat, Jun 22, 2019 at 12:25:30PM +0200, Stephane HUC "PengouinBSD" wrote: 
>>> >> (...) >> >> Perhaps, for Firefox, it's a problem with pledge? >> >>
>> I see thoses messages in /var/log/messages - egual on 'dmesg': >> >> Jun
>> 22 11:21:21 ptb-z /bsd: firefox[1]: pledge "flock", syscall 92 >>
>> Jun 22 11:21:21 ptb-z /bsd: firefox[17962]: pledge "flock", syscall 92
 Jun 22 11:21:22 ptb-z /bsd: firefox[47501]: pledge "flock", syscall
>> 92 >> >> (...) >> >> firefox[68021]: pledge "flock", syscall 92 >>
>> firefox[22469]: pledge "flock", syscall 92 >> firefox[41244]: pledge
>> "flock", syscall 92 >> >> ??? > > This happens sometimes when firefox is
>> calling into some library that > hits these syscalls, and those syscalls
>> are not in the firefox pledge. > In my experience this is often some
>> uncommon code path through X, > usually related to which graphics driver
>> you are using, but it could be > anything. When I have this happen to
>> me, it is always on specific > websites that trigger some rendering
>> codepath through X that uses some > unusual way to allocate memory or
>> something. In your case, it could also > be some extension you have
>> loaded. > > You can pretty easily see what is going wrong: > > When a
>> firefox tab crashes you should have a firefox.core file lying > around
>> (usually in your $HOME, but it will be wherever you launched > firefox
>> from). Run gdb on /usr/local/bin/firefox, and then load up the > core
>> file. It will drop you into the spot where firefox was killed, and > you
>> can check the backtrace to see what code path took you to the system >
>> call that hasn't been pledged. > > In this instance, firefox is calling
>> fcntl, which is covered by the > "flock" pledge. You can add "flock" to
>> the > security.sandbox.pledge.content line in about:config and see if
>> that > makes it work for you. If you have at all modified the firefox
>> content > or main pledges from their defaults, you should check to see
>> if > reverting to their defaults helps ("flock" is in the main pledge by
>>> default, but not in the content pledge). > > Hope this helps.
>> Hi,
>>
>> Now, Firefox tab crash; as you wrote, I try gdb:
>>
>> $ gdb /usr/local/bin/firefox
>> GNU gdb 6.3
>> Copyright 2004 Free Software Foundation, Inc.
>> GDB is free software, covered by the GNU General Public License, and you are
>> welcome to change it and/or distribute copies of it under certain
>> conditions.
>> Type "show copying" to see the conditions.
>> There is absolutely no warranty for GDB.  Type "show warranty" for details.
>> This GDB was configured as "amd64-unknown-openbsd6.5"...(no debugging
>> symbols found)
>>
>> (gdb) core-file firefox.core
>> warning: Couldn't find general-purpose registers in core file.
>>
>> warning: Couldn't find general-purpose registers in core file.
>>
>> #0  0x in ?? ()
>> (gdb) backtrace
>> #0  0x in ?? ()
>> Cannot access memory at address 0x0
>> (gdb) q
>>
>> What do you want another?
>>
>>
>> -- 
>> ~ " Fully Basic System Distinguish Life! " ~ " Libre as a BSD " +=<<<
>> 
>> Stephane HUC as PengouinBSD or CIOTBSD
>> b...@stephane-huc.net
>>
>>
-- 
~ " Fully Basic System 

Core firefox, was: (Re: alc0 watchdog timeout)

[PengouinBSD]

On 6/22/19 5:32 PM, Todd Mortimer wrote:
> On Sat, Jun 22, 2019 at 12:25:30PM +0200, Stephane HUC "PengouinBSD" wrote: 
> >> (...) >> >> Perhaps, for Firefox, it's a problem with pledge? >> >>
I see thoses messages in /var/log/messages - egual on 'dmesg': >> >> Jun
22 11:21:21 ptb-z /bsd: firefox[1]: pledge "flock", syscall 92 >>
Jun 22 11:21:21 ptb-z /bsd: firefox[17962]: pledge "flock", syscall 92
>> Jun 22 11:21:22 ptb-z /bsd: firefox[47501]: pledge "flock", syscall
92 >> >> (...) >> >> firefox[68021]: pledge "flock", syscall 92 >>
firefox[22469]: pledge "flock", syscall 92 >> firefox[41244]: pledge
"flock", syscall 92 >> >> ??? > > This happens sometimes when firefox is
calling into some library that > hits these syscalls, and those syscalls
are not in the firefox pledge. > In my experience this is often some
uncommon code path through X, > usually related to which graphics driver
you are using, but it could be > anything. When I have this happen to
me, it is always on specific > websites that trigger some rendering
codepath through X that uses some > unusual way to allocate memory or
something. In your case, it could also > be some extension you have
loaded. > > You can pretty easily see what is going wrong: > > When a
firefox tab crashes you should have a firefox.core file lying > around
(usually in your $HOME, but it will be wherever you launched > firefox
from). Run gdb on /usr/local/bin/firefox, and then load up the > core
file. It will drop you into the spot where firefox was killed, and > you
can check the backtrace to see what code path took you to the system >
call that hasn't been pledged. > > In this instance, firefox is calling
fcntl, which is covered by the > "flock" pledge. You can add "flock" to
the > security.sandbox.pledge.content line in about:config and see if
that > makes it work for you. If you have at all modified the firefox
content > or main pledges from their defaults, you should check to see
if > reverting to their defaults helps ("flock" is in the main pledge by
> default, but not in the content pledge). > > Hope this helps.
Hi,

Now, Firefox tab crash; as you wrote, I try gdb:

$ gdb /usr/local/bin/firefox
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-unknown-openbsd6.5"...(no debugging
symbols found)

(gdb) core-file firefox.core
warning: Couldn't find general-purpose registers in core file.

warning: Couldn't find general-purpose registers in core file.

#0  0x in ?? ()
(gdb) backtrace
#0  0x in ?? ()
Cannot access memory at address 0x0
(gdb) q

What do you want another?


-- 
~ " Fully Basic System Distinguish Life! " ~ " Libre as a BSD " +=<<<

Stephane HUC as PengouinBSD or CIOTBSD
b...@stephane-huc.net

Re: openrsync crashes when syncing local source and local destination

[Aaron Rydberg]

Sorry the command I posted was not specific.
Adding --rsync-path=/usr/bin/openrsync solved the problem as 
I no longer have packaged rsync installed.  The problem was the
same when syncing directories with -a

Here is a specific example.

openrsync -v .cwmrc test/
/usr/src/usr.bin/rsync/io.c:224: error: unexpected end of file
/usr/src/usr.bin/rsync/io.c:247: error: io_read_nonblocking
/usr/src/usr.bin/rsync/io.c:638: error: io_read_buf
/usr/src/usr.bin/rsync/client.c:56: error: io_read_int

openrsync -v --rsync-path=/usr/bin/opensrync .cwmrc test/
Transfer starting: 1 files
.cwmrc
Transfer complete: 54 B sent, 92 B read, 1.5 KB file size

Thanks for your help.


On Wed, Jun 26, 2019, at 4:58 PM, Kristaps Dzonsons wrote:
> > is it a case that the source and destination directory are the same ?
> > ..is that the issue at hand ?
> 
> Tom,
> 
> Doesn't matter when I try it.
> 
> Aaron, I am able to cause a premature exit by running against a source
> machine's rsync that doesn't exist.  By default, openrsync will invoke
> "rsync".  So if you're running
> 
>  % openrsync whatever wherever
> 
> It will look for "rsync" on the local computer.  On my machine:
> 
> % /usr/bin/openrsync --rsync-path /usr/bin/muppet -v xyzzy/ xyzzy/
> io.c:224: error: unexpected end of file
> io.c:247: error: io_read_nonblocking
> io.c:638: error: io_read_buf
> client.c:56: error: io_read_int
> 
> Is this the case with you?  You can verify by running:
> 
> % /usr/bin/openrsync --rsync-path /usr/bin/openrsync -v xyzzy/ xyzzy/
> flist.c:1076: warning: xyzzy/: skipping directory
> Transfer starting: 0 files
> Transfer complete: 16 B sent, 17 B read, 0 B file size
> 
> Of course, if you use -a,
> 
> % /usr/bin/openrsync --rsync-path /usr/bin/openrsync -va xyzzy/ xyzzy/
> Transfer starting: 64 files
> Transfer complete: 16 B sent, 2.3 KB read, 290.6 KB file size
> 
> Either way, I'll cook up a patch to have an error message following the
> execvp in main.c.
> 
> Best,
> 
> Kristaps
> 
>

Re: Route through different gateways depending on process

[slackwaree]

Hello,

Well this is not so simple as it looks but I have made success with traceroute.

route -T1 exec '/usr/sbin/traceroute' -n
route -T2 exec '/usr/sbin/traceroute' -n
route -T3 exec '/usr/sbin/traceroute' -n

Goes out on proper gateways so it works.

For Squid things gets a little bit more complicated.

For example I use squidguard which is spawned by squid so I don't know if the 
alternative routing table applied to this as well.

 |-+= 03951 root /usr/local/sbin/squid
 | \--- 06369 _squid (squid-1) --kid squid-1 (squid)

When I start squid I get:


 route -T3 exec '/usr/local/sbin/squid'
2019/06/26 14:50:35| WARNING: (B) '127.0.0.1' is a subnetwork of (A) '127.0.0.1'
2019/06/26 14:50:35| WARNING: because of this '127.0.0.1' is ignored to keep 
splay tree searching predictable
2019/06/26 14:50:35| WARNING: You should probably remove '127.0.0.1' from the 
ACL named 'localhost'
2019/06/26 14:50:35| WARNING: (B) '127.0.0.1' is a subnetwork of (A) '127.0.0.1'
2019/06/26 14:50:35| WARNING: because of this '127.0.0.1' is ignored to keep 
splay tree searching predictable
2019/06/26 14:50:35| WARNING: You should probably remove '127.0.0.1' from the 
ACL named 'localhost'
2019/06/26 14:50:35| WARNING: (B) '::1' is a subnetwork of (A) '::1'
2019/06/26 14:50:35| WARNING: because of this '::1' is ignored to keep splay 
tree searching predictable
2019/06/26 14:50:35| WARNING: You should probably remove '::1' from the ACL 
named 'localhost'
2019/06/26 14:50:35| WARNING: (B) '::1' is a subnetwork of (A) '::1'
2019/06/26 14:50:35| WARNING: because of this '::1' is ignored to keep splay 
tree searching predictable
2019/06/26 14:50:35| WARNING: You should probably remove '::1' from the ACL 
named 'localhost'
2019/06/26 14:50:35| WARNING: (B) '127.0.0.0/8' is a subnetwork of (A) 
'127.0.0.0/8'
2019/06/26 14:50:35| WARNING: because of this '127.0.0.0/8' is ignored to keep 
splay tree searching predictable
2019/06/26 14:50:35| WARNING: You should probably remove '127.0.0.0/8' from the 
ACL named 'to_localhost'
2019/06/26 14:50:35| WARNING: (B) '0.0.0.0' is a subnetwork of (A) '0.0.0.0'
2019/06/26 14:50:35| WARNING: because of this '0.0.0.0' is ignored to keep 
splay tree searching predictable
2019/06/26 14:50:35| WARNING: You should probably remove '0.0.0.0' from the ACL 
named 'to_localhost'
2019/06/26 14:50:35| WARNING: (B) '0.0.0.0' is a subnetwork of (A) '0.0.0.0'
2019/06/26 14:50:35| WARNING: because of this '0.0.0.0' is ignored to keep 
splay tree searching predictable
2019/06/26 14:50:35| WARNING: You should probably remove '0.0.0.0' from the ACL 
named 'to_localhost'
2019/06/26 14:50:35| WARNING: (B) '::1' is a subnetwork of (A) '::1'
2019/06/26 14:50:35| WARNING: because of this '::1' is ignored to keep splay 
tree searching predictable
2019/06/26 14:50:35| WARNING: You should probably remove '::1' from the ACL 
named 'to_localhost'
2019/06/26 14:50:35| WARNING: (B) '::1' is a subnetwork of (A) '::1'
2019/06/26 14:50:35| WARNING: because of this '::1' is ignored to keep splay 
tree searching predictable
2019/06/26 14:50:35| WARNING: You should probably remove '::1' from the ACL 
named 'to_localhost'
2019/06/26 14:50:35| ERROR: Directive 'url_rewrite_concurrency' is obsolete.
2019/06/26 14:50:35| WARNING: url_rewrite_concurrency upgrade overriding 
url_rewrite_children settings.

I see that this might be an issue of the loopback not being present on that 
table so I have added:


route -T3 add -net 127.0.0.0/8 127.0.0.1
route -T3 add -host localhost localhost

route -T3 show
Routing tables

Internet:
DestinationGatewayFlags   Refs  Use   Mtu  Prio Iface
default192.168.10.252 UGS05 - 8 vio0
127/8  localhost  UGS01 32768 8 lo0
localhost  localhost  UGHS   00 32768 8 lo0

IPV4 I don't need.
Maybe I did not add the localhost correctly?! since if I compare this with the 
main routing table I see different flags:
127/8  localhost  UGRS   00 32768 8 lo0
localhost  localhost  UHhl   3   98 32768 1 lo0

Anyway Squid starts  with the mentioned warnings but any request I try to make 
through it hangs.


‐‐‐ Original Message ‐‐‐
On Monday, June 24, 2019 11:07 AM, Claudio Jeker  
wrote:

> On Mon, Jun 24, 2019 at 08:47:38AM +, slackwaree wrote:
>
> > Hello,
> > Could you maybe provide a full case study for this as it is fairly
> > uncommon task?
> > Do you mean that I will also need +2 ip aliases next to the boxes main ip?
>
> No. You can use either option. The question is how are the proxy users
> talking to those 3 different proxies? If you want to use port 8080 for all
> of them you want 3 different IPs.
>
> > Eg instead of
> > 192.168.10.1: 3128 3129 3130
> > 192.168.10.1:3128 using gateway 192.168.10.250
> > 192.168.10.2:3128 using gateway 192.168.10.251
> > 192.168.10.3:3128 using gateway 192.168.10.252
>
> Try 

Re: openrsync crashes when syncing local source and local destination

[Kristaps Dzonsons]

> is it a case that the source and destination directory are the same ?
> ..is that the issue at hand ?

Tom,

Doesn't matter when I try it.

Aaron, I am able to cause a premature exit by running against a source
machine's rsync that doesn't exist.  By default, openrsync will invoke
"rsync".  So if you're running

 % openrsync whatever wherever

It will look for "rsync" on the local computer.  On my machine:

% /usr/bin/openrsync --rsync-path /usr/bin/muppet -v xyzzy/ xyzzy/
io.c:224: error: unexpected end of file
io.c:247: error: io_read_nonblocking
io.c:638: error: io_read_buf
client.c:56: error: io_read_int

Is this the case with you?  You can verify by running:

% /usr/bin/openrsync --rsync-path /usr/bin/openrsync -v xyzzy/ xyzzy/
flist.c:1076: warning: xyzzy/: skipping directory
Transfer starting: 0 files
Transfer complete: 16 B sent, 17 B read, 0 B file size

Of course, if you use -a,

% /usr/bin/openrsync --rsync-path /usr/bin/openrsync -va xyzzy/ xyzzy/
Transfer starting: 64 files
Transfer complete: 16 B sent, 2.3 KB read, 290.6 KB file size

Either way, I'll cook up a patch to have an error message following the
execvp in main.c.

Best,

Kristaps

Re: openrsync crashes when syncing local source and local destination

[Tom Smyth]

is it a case that the source and destination directory are the same ?
..is that the issue at hand ?

On Wed, 26 Jun 2019 at 10:42, Kristaps Dzonsons  wrote:
>
> > openrsync crashes when sycning local files.  It was working a few days
> > ago but after upgrading current it produces this error.  No files are
> > transferred.
> >
> > openrsync -v local-dir/ local-dir/
> >
> > /usr/src/usr.bin/rsync/io.c:224: error: unexpected end of file
> > /usr/src/usr.bin/rsync/io.c:247: error: io_read_nonblocking
> > /usr/src/usr.bin/rsync/io.c:638: error: io_read_buf
> > /usr/src/usr.bin/rsync/client.c:56: error: io_read_int
> >
> > uname -a
> > OpenBSD laptop.home.net 6.5 GENERIC.MP#69 amd64
>
> I can't reproduce this, but I think you've copy and pasted things wrong.
>  You were really running openrsync with two directories (the same
> directories, mind you) and not -a?  Is there an openrsync.core anywhere
> whose backtrace you can get?
>
> Can you run with - and paste your exact invocation?  And again with
> --rsync-path openrsync as well?
>
> Also, can you tail /var/log/messages to see if there's anything in there?
>


-- 
Kindest regards,
Tom Smyth.

Re: openrsync crashes when syncing local source and local destination

[Kristaps Dzonsons]

> openrsync crashes when sycning local files.  It was working a few days
> ago but after upgrading current it produces this error.  No files are 
> transferred.
> 
> openrsync -v local-dir/ local-dir/
> 
> /usr/src/usr.bin/rsync/io.c:224: error: unexpected end of file
> /usr/src/usr.bin/rsync/io.c:247: error: io_read_nonblocking
> /usr/src/usr.bin/rsync/io.c:638: error: io_read_buf
> /usr/src/usr.bin/rsync/client.c:56: error: io_read_int
> 
> uname -a
> OpenBSD laptop.home.net 6.5 GENERIC.MP#69 amd64

I can't reproduce this, but I think you've copy and pasted things wrong.
 You were really running openrsync with two directories (the same
directories, mind you) and not -a?  Is there an openrsync.core anywhere
whose backtrace you can get?

Can you run with - and paste your exact invocation?  And again with
--rsync-path openrsync as well?

Also, can you tail /var/log/messages to see if there's anything in there?

openrsync crashes when syncing local source and local destination

[Aaron Rydberg]

Hi,

openrsync crashes when sycning local files.  It was working a few days
ago but after upgrading current it produces this error.  No files are 
transferred.

openrsync -v local-dir/ local-dir/

/usr/src/usr.bin/rsync/io.c:224: error: unexpected end of file
/usr/src/usr.bin/rsync/io.c:247: error: io_read_nonblocking
/usr/src/usr.bin/rsync/io.c:638: error: io_read_buf
/usr/src/usr.bin/rsync/client.c:56: error: io_read_int

uname -a
OpenBSD laptop.home.net 6.5 GENERIC.MP#69 amd64

Thanks.