Re: [OpenIndiana-discuss] ntpd has issues after upgraded to latest OI Hipster release today

2023-10-13 Thread Bill Sommerfeld via openindiana-discuss

On 7/29/23 13:31, Marcel Telka wrote:

On Sat, Jul 29, 2023 at 03:06:50PM +0100, russell wrote:

Jul 29 13:21:14 tesla ntpd[1283]: [ID 702911 ntp.error] 
/jenkins/jobs/oi-userland/workspace/components/network/ntp/ntp-4.2.8p17/libntp/recvbuff.c:383:
REQUIRE(((void *)0) == pf->pptail || pptail == pf->pptail) failed


This is an old and well known bug in ntp:
https://bugs.ntp.org/show_bug.cgi?id=3552


This has been hitting my systems periodically and I took a look.

Looking through the code, I stumbled upon this block in recvbuff.c:

#if defined(SYS_WINNT)

/*
 * For Windows we need to set up a lock to manipulate the
 * recv buffers to prevent corruption. We keep it lock for as
 * short a time as possible
 */
static CRITICAL_SECTION RecvLock;
static CRITICAL_SECTION FreeLock;
# define LOCK_R()   EnterCriticalSection()
# define UNLOCK_R() LeaveCriticalSection()
# define LOCK_F()   EnterCriticalSection()
# define UNLOCK_F() LeaveCriticalSection()

...

The openindiana build of ntpd will sporadically spawn a second thread 
for background processing for things like DNS lookups, so I hacked 
together a patch (attached; probably #ifdef'ed on the wrong thing) to 
add a lock for illumos as well.


___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] mariadb secure installation script infinite loop

2024-01-23 Thread Bill Sommerfeld via openindiana-discuss

On 1/23/24 16:36, Christopher D. Bartels wrote:

EDIT:

This is what gives me the error, sorry for omitting it previously:

ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 
'Password';


You probably want to take a look at https://mariadb.com/kb/en/alter-user/
which suggests:

CREATE USER 'bob'@'localhost'
  IDENTIFIED VIA mysql_native_password USING PASSWORD('pwd')
  OR unix_socket;

and

ALTER USER 'bob'@'localhost' IDENTIFIED VIA mysql_native_password
  USING PASSWORD('pwd2');

There are a bunch of variant syntaxes for when you're supplying the password 
hash instead of the plaintext password.

As an aside, I've found "IDENTIFIED VIA unix_socket" to be the way to go for 
local access when the client is on the same machine as the database.


___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] Python abstact socket and config printer applet.py

2023-12-13 Thread Bill Sommerfeld via openindiana-discuss

On 12/13/23 15:03, Joshua M. Clulow via openindiana-discuss wrote:

On Wed, 13 Dec 2023 at 09:24, Carsten Grzemba via openindiana-discuss
 wrote:

A sock.bind with an normal string works, but not the style with the leading \0. 
This is the syntax for abstract sockets on Linux.
I have no idea if abstract sockets would work on Illumos and Python. But how 
should work the printer applet on non Linux systems?


You will need to put the socket in a directory with the appropriate permissions.

Note that any user on the system can connect() to a UNIX socket if
they can see the directory entry for it, regardless of the permissions
on the socket entry itself.  If the socket server is not using
getpeerucred(3C) or equivalent to inspect the credentials of the
connecting process, you should put the socket in a directory owned by
the user with mode 0700 to prevent connections from unauthorised
processes.


A quick look at the applet.py code shows that it creates the bound 
socket as a lock (to prevent multiple instances from running as the same 
user) but never uses it for anything or passes it to anything outside 
the "__main__" block.


So there's no need to prevent connections - the daemon will never call 
sock.accept()



___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] Python abstact socket and config printer applet.py

2023-12-13 Thread Bill Sommerfeld via openindiana-discuss

On 12/13/23 09:24, Carsten Grzemba via openindiana-discuss wrote:

I don't know when I have seen the last time the printer applet in mate-panel.

On my attempts to revive the applet I stumbled on the abstract socket stuff in 
the Python code of applet.py

If i try to start

/usr/share/system-config-printer/applet.py I get the exception

Process already running (2:No such file or directory). Exiting.


For the used syntax

sock.bind("\0printer-applet-lock-user-" + getpass.getuser())
the error is 2:No such file or directory, the "Process already running" notice 
is the interpretation of the exception handler

A sock.bind with an normal string works, but not the style with the leading \0. 
This is the syntax for abstract sockets on Linux.
I have no idea if abstract sockets would work on Illumos and Python. But how 
should work the printer applet on non Linux systems?



Linux unix(7) says:

> The abstract socket namespace is a nonportable Linux extension.

It looks like there's support for this in the out-of-illumos-gate lx brand:

https://github.com/TritonDataCenter/illumos-joyent/blob/master/usr/src/uts/common/brand/lx/syscall/lx_socket.c#L390

but that's not handled in the native syscall.

But you can very much do in userspace what this does in the kernel: 
replace the NUL at the start of the pathname with the path to a 
sticky-bitted world-writable directory.


This appears to fix it for me:

--- applet.py~  Tue Mar 14 12:01:25 2023
+++ applet.py   Wed Dec 13 14:59:02 2023
@@ -464,7 +464,7 @@
 try:
 sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
 # Create an abstract socket, by prefixing it with null.
-sock.bind("\0printer-applet-lock-user-" + getpass.getuser())
+sock.bind("/tmp/printer-applet-lock-user-" + getpass.getuser())
 except socket.error as err:
 error_code = err.args[0]
 error_string = err.args[1]

but maybe /tmp isn't the best place..



___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] DNS server and domain from DHCP?

2023-12-20 Thread Bill Sommerfeld via openindiana-discuss
Autoconfiguration of /etc/resolv.conf on illumos could really use some 
attention and modernization - besides the glitch you noticed, there is 
also currently no way to automatically use ipv6 nameserver addresses 
either from DHCPv6 or IPv6 stateless address autoconfig.


Funnelling the settings through SMF properties would absolutely make 
sense as any dual-stack config necessarily must merge config from 
multiple sources.


On 12/20/23 09:18, Philip Kime wrote:

Strangely, after another reboot, /etc/resolv.conf now contains the domain and 
nameserver from DHCP ...

PK
--
Dr Phil. Philip Kime
BA (Hons) Msc (Dist) PhD


On 19 Dec 2023, at 21:09, Joshua M. Clulow via openindiana-discuss 
 wrote:

On Tue, 19 Dec 2023 at 11:14, Peter Tribble  wrote:

On Tue, Dec 19, 2023 at 6:33 PM Philip Kime  wrote:

I have used ipadm to configure an interface via DHCP, which works find.
However, the DHCP server also provide the DNS server and default domain
which was not being set on my server. I found that I had entries in
/etc/resolv.conf which seem to be set by SMF and are repopulated after
reboot. Two questions:

* Where can I find the dns server and domain settings in SMF? I tried
looking in dns/client but I can't see config/nameserver property in there.



I wonder if this is nwam. It can also save and restore network settings,
apparently.
Some details are embedded in /lib/svc/method/net-loc and
/lib/svc/method/net-nwam,
but I'm not sure if there's much in the way of accurate documentation.

(But I would start with:
/usr/sbin/nwamcfg list
/usr/sbin/nwamcfg "select loc Automatic ; get -V dns-nameservice-configsrc"
and investigate from there.)


It would be good to know if you're using nwam or the classic
ipadm-style configuration, first.  What output do you get from:

svcs network/physical


Cheers.

--
Joshua M. Clulow
http://blog.sysmgr.org

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss




___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss



___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] Questions about /var/pkg

2024-01-13 Thread Bill Sommerfeld via openindiana-discuss

On 1/13/24 15:20, Andreas Wacknitz via openindiana-discuss wrote:

Am 14.01.24 um 00:13 schrieb Goetz T. Fischer:
i'm afraid making ips fast needs more than just a cython module here 
and there.
don't get me wrong, that's not indiana's fault but a genernal ips 
issue. maybe having a closer look at

mr. Wegmueller's go version would be a good idea after all.

If you want to make IPS fast you will probably need more than switching
the implementation language.
As Aurélien mentioned, IPS is using a SAT solver. So it might be
necessary to also change the algorithms.
Are you sure that you can devote enough time to achieve real advantages?


Any such effort should start by profiling to see where the time actually 
goes - don't assume the SAT solver is eating it all.  My casual pokes at 
it showed a lot of time going into manipulating the on-disk metadata, 
with a lot of short write() syscalls instead of using buffered I/O - but 
that may not have been a representative sampling of where the time goes.


- Bill



___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] new be doesn't keep zfs settings

2024-01-17 Thread Bill Sommerfeld via openindiana-discuss

On 1/17/24 16:22, Goetz T. Fischer wrote:

On Wed, 17 Jan 2024 14:34:59 +0100, Marcel Telka wrote:

On Wed, Jan 17, 2024 at 08:01:22AM +0100, Goetz T. Fischer wrote:

however, the catch was that the new be, that's created during a "pkg update", 
doesn't keep the
compression setting. after the reboot i noticed that the new /var had 
compression set to off again and
therefore was big again. is there something specific i have to do to make the 
new be keep the zfs
settings?


I'd expect this to work out of the box. Could you please share how
exaclty this could be reproduced?


sure, this is the pool of my test installation:

rpool  5.63G  5.51G  124K  /rpool
rpool/ROOT 5.03G  5.51G   96K  legacy
rpool/ROOT/openindiana-2024:01:15  5.03G  5.51G 4.15G  /
rpool/ROOT/openindiana-2024:01:15/var   905M  5.51G  905M  /var
rpool/dump 64.1M  5.51G 64.1M  -
rpool/export192K  5.51G   96K  /export
rpool/export/home96K  5.51G   96K  /export/home
rpool/swap  546M  6.03G 13.9M  -

then i run:
root@openindiana:~# zfs set compression=on rpool/ROOT/openindiana-2024:01:15/var
root@openindiana:~# zfs get compression rpool/ROOT/openindiana-2024:01:15/var
NAME   PROPERTY VALUE SOURCE
rpool/ROOT/openindiana-2024:01:15/var  compression  onlocal

and then, as described, after a "pkg update" the compression of the new be's 
/var is gone again.


While this doesn't directly answer your question as to what's going on,
I generally set compression on the root filesystem of the BE - or on the 
never-mounted parent rpool/ROOT filesystem - and it would be inherited 
from there onto any children like /var; ZFS compression is fast enough 
that you really want it on everywhere except when you know that most of 
what is being stored isn't compressable.


If you want to dig into what's going on I'd look carefully at the code 
in libbe (usr/src/lib/libbe/common/*) and see where it gets properties 
for each filesystem it creates when it's cloning a new BE from an 
existing one.


- Bill



___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] 32-bit libraries disappearing

2024-01-07 Thread Bill Sommerfeld via openindiana-discuss

On 1/7/24 07:26, Till Wegmueller wrote:
I would like to continue with what marcel proposed though as it seems 
you have other software aswell like conky which is not from the 
OpenIndiana repositories.


These days sqlite3 has become so widely used as a library that maybe we 
should keep around the 32-bit libsqlite3 until we're ready to get rid of 
the 32-bit libc.


- Bill


___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] Questions about /var/pkg

2024-01-12 Thread Bill Sommerfeld via openindiana-discuss

On 1/12/24 06:49, Marcel Telka wrote:

On Fri, Jan 12, 2024 at 08:21:17AM -0600, Matthew R. Trower wrote:

If uninstalling a package places files in lost+found, then I'm well and
truly confused.


To confuse you a bit more here is an example:

# find /var/pkg/lost+found/ -type f
# echo test > 
/usr/lib/python3.9/vendor-packages/pytest_randomly-3.15.0.dist-info/TEST
# pkg uninstall pytest-randomly-39 pytest-randomly
...
# find /var/pkg/lost+found/ -type f
/var/pkg/lost+found/usr/lib/python3.9/vendor-packages/pytest_randomly-3.15.0.dist-info-20240112T154031Z/TEST
# cat 
/var/pkg/lost+found/usr/lib/python3.9/vendor-packages/pytest_randomly-3.15.0.dist-info-20240112T154031Z/TEST
test
#


Just to clarify what happened here, Marcel added a file to an 
IPS-created directory then deleted the only package that caused that 
directory to exist.   IPS deleted the files it managed, moved the 
leftovers to a subdirectory of /var/pkg/lost+found, then deleted the 
directory.




___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] Questions about /var/pkg

2024-01-12 Thread Bill Sommerfeld via openindiana-discuss

On 1/12/24 16:06, Matthew R. Trower wrote:

Interesting, I only knew of attributes(5).  It appears attributes(7) may
have shared a common root, but has long since diverged (or maybe they're
just encoded differently).  Still, they appear identical in regards to 
the Interface Stability attribute.


Today, illumos-gate has only attributes(7).

I believe you have stale preformatted man pages from a system installed 
before https://www.illumos.org/issues/14443 landed, likely in 
/usr/man/cat?/ directories that are no longer used by the current 
install but which are still searched by man(1)


Clean out the old /usr/man/cat* directories and all should be better.

See also https://github.com/illumos/ipd/blob/master/ipd/0004/README.md

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] no force write by root user?

2024-03-10 Thread Bill Sommerfeld via openindiana-discuss

On 3/10/24 08:16, Rolf M. Dietze wrote:

what does "W" in 'cpoptions' mean? Is that a setup probem with
my shell? (zsh, same .zshrc as on FreeBSD and Oracle Solaris)
with modified PATH setup...


I'm not a vim user but I quickly found:

https://vimdoc.sourceforge.net/htmldoc/options.html#'cpoptions'

> A sequence of single character flags.  When a character is present
> this indicates vi-compatible behavior.  This is used for things where
> not being vi-compatible is mostly or sometimes preferred.
> 'cpoptions' stands for "compatible-options".
...
> W  Don't overwrite a readonly file.  When omitted, ":w!"
>overwrites a readonly file, if possible.

That same document has a long list of places vim might find 
configuration options:


https://vimdoc.sourceforge.net/htmldoc/starting.html#initialization

- Bill


___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] no force write by root user?

2024-03-09 Thread Bill Sommerfeld via openindiana-discuss

On 3/9/24 16:31, Rolf M. Dietze wrote:

Hello,

if the root user wants to write back a file not writable as set by
permissions a force write back (wq! in vi) does not work. Is that
behavior intended? Other OSes as for instance oracle solaris, FreeBSD,
Solaris 10 and so, allow a force write back

/rmd


I can't reproduce; there must be something else at play (like a 
read-only mount or unusual acls).


# touch /var/tmp/noway
# chmod 444 /var/tmp/noway
# cat /var/tmp/noway
# vi /var/tmp/noway

(I type "ifoo  :wq!)

# cat /var/tmp/noway
foo


___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss