Re: sysupgrade - timezone
On 19.9.2022. 23:22, Todd C. Miller wrote: > There was a bad diff in that snapshot that caused tzset() to ignore > /etc/localtime. > > - todd > Thank you ...
Re: sysupgrade - timezone
There was a bad diff in that snapshot that caused tzset() to ignore /etc/localtime. - todd
Re: sysupgrade - timezone
On 19.9.2022. 23:09, Todd C. Miller wrote: > On Mon, 19 Sep 2022 23:06:13 +0200, Hrvoje Popovski wrote: > >> after sysupgrade I'm having GMT >> >> OpenBSD 7.2 (GENERIC.MP) #736: Mon Sep 19 17:56:55 GMT 2022 >> r620-1# date >> Mon Sep 19 21:01:14 GMT 2022 >> >> r620-1# ls -apl /etc/localtime >> lrwxr-xr-x 1 root wheel 33 Feb 10 2022 /etc/localtime -> >> /usr/share/zoneinfo/Europe/Zagreb >> >> I didn't upgrade r420-1 yet, but other boxes are upgraded to latest snapshot > > Can you check the permissions on /usr/share/zoneinfo/Europe/Zagreb? > If that file is not readable you will end up with GMT. > r620-1# ls -apl /usr/share/zoneinfo/Europe/Zagreb -r--r--r-- 1 root bin 1917 Sep 19 17:39 /usr/share/zoneinfo/Europe/Zagreb > If it looks OK, what does: > > TZ=Europe/Zagreb date > > produce? > r620-1# TZ=Europe/Zagreb date Mon Sep 19 23:13:26 CEST 2022 > - todd >
Re: sysupgrade - timezone
On Mon, 19 Sep 2022 23:06:13 +0200, Hrvoje Popovski wrote: > after sysupgrade I'm having GMT > > OpenBSD 7.2 (GENERIC.MP) #736: Mon Sep 19 17:56:55 GMT 2022 > r620-1# date > Mon Sep 19 21:01:14 GMT 2022 > > r620-1# ls -apl /etc/localtime > lrwxr-xr-x 1 root wheel 33 Feb 10 2022 /etc/localtime -> > /usr/share/zoneinfo/Europe/Zagreb > > I didn't upgrade r420-1 yet, but other boxes are upgraded to latest snapshot Can you check the permissions on /usr/share/zoneinfo/Europe/Zagreb? If that file is not readable you will end up with GMT. If it looks OK, what does: TZ=Europe/Zagreb date produce? - todd
sysupgrade - timezone
Hi all, before sysupgrade I had CEST timezone OpenBSD 7.2 (GENERIC.MP) #733: Sun Sep 18 06:39:56 MDT 2022 r420-1# date Mon Sep 19 22:59:37 CEST 2022 r420-1# ls -apl /etc/localtime lrwxr-xr-x 1 root wheel 33 Nov 12 2019 /etc/localtime -> /usr/share/zoneinfo/Europe/Zagreb after sysupgrade I'm having GMT OpenBSD 7.2 (GENERIC.MP) #736: Mon Sep 19 17:56:55 GMT 2022 r620-1# date Mon Sep 19 21:01:14 GMT 2022 r620-1# ls -apl /etc/localtime lrwxr-xr-x 1 root wheel 33 Feb 10 2022 /etc/localtime -> /usr/share/zoneinfo/Europe/Zagreb I didn't upgrade r420-1 yet, but other boxes are upgraded to latest snapshot
Re: sysupgrade - Reading from socket: Undefined error: 0
On 19.9.2022. 22:27, Hrvoje Popovski wrote: > Hi all, > > when doing sysupgrade few minutes ago on multiple machines i'm getting > error in subject > > smc24# sysupgrade -s > Fetching from https://cdn.openbsd.org/pub/OpenBSD/snapshots/amd64/ > SHA256.sig 100% |*| > 2144 00:00 > Signature Verified > INSTALL.amd64 100% || > 43554 00:00 > base72.tgz 100% |*| > 331 MB00:16 > bsd 100% |*| > 22449 KB00:05 > bsd.mp 100% |*| > 22562 KB00:04 > bsd.rd 100% |*| > 4533 KB00:01 > comp72.tgz 100% |*| > 74598 KB00:09 > game72.tgz 100% |*| > 2745 KB00:01 > man72.tgz100% |*| > 7610 KB00:02 > xbase72.tgz 29% |** | > 15744 KB00:14 ETAsysupgrade: Reading from socket: Undefined error: 0 > smc24# > If I run it again sysupgrade seems fine smc24# sysupgrade -s Fetching from https://cdn.openbsd.org/pub/OpenBSD/snapshots/amd64/ SHA256.sig 100% |*| 2144 00:00 Signature Verified Verifying old sets. xbase72.tgz 100% |*| 52806 KB00:07 xfont72.tgz 100% |*| 22967 KB00:05 xserv72.tgz 100% |*| 14815 KB00:03 xshare72.tgz 100% |*| 4559 KB00:01 Verifying sets. Fetching updated firmware. fw_update: added none; updated none; kept vmm Upgrading.
sysupgrade - Reading from socket: Undefined error: 0
Hi all, when doing sysupgrade few minutes ago on multiple machines i'm getting error in subject smc24# sysupgrade -s Fetching from https://cdn.openbsd.org/pub/OpenBSD/snapshots/amd64/ SHA256.sig 100% |*| 2144 00:00 Signature Verified INSTALL.amd64 100% || 43554 00:00 base72.tgz 100% |*| 331 MB00:16 bsd 100% |*| 22449 KB00:05 bsd.mp 100% |*| 22562 KB00:04 bsd.rd 100% |*| 4533 KB00:01 comp72.tgz 100% |*| 74598 KB00:09 game72.tgz 100% |*| 2745 KB00:01 man72.tgz100% |*| 7610 KB00:02 xbase72.tgz 29% |** | 15744 KB00:14 ETAsysupgrade: Reading from socket: Undefined error: 0 smc24#
bgpd speed up pathid_assign() for the common case
When running on busy bgpd servers with many clients the function
pathid_assign() consumes a lot of CPU time. The code does a lookup which
often fails and then walks the list of prefixes. In the end this is
results in two list walks.
This complicated dance is only needed for peers that use add-path but
regular peers can skip this by assigning a per peer path_id instead.
To make this work even path_id_txs are for regular peers while the
add-path peers use even numbers.
This should help route collectors and route reflectors that receive the
same route many times from different sources. At least as long as these
peers don't use add-path.
--
:wq Claudio
Index: rde.c
===
RCS file: /cvs/src/usr.sbin/bgpd/rde.c,v
retrieving revision 1.576
diff -u -p -r1.576 rde.c
--- rde.c 12 Sep 2022 10:03:17 - 1.576
+++ rde.c 19 Sep 2022 15:29:19 -
@@ -1607,28 +1607,38 @@ pathid_conflict(struct rib_entry *re, ui
return 0;
}
+/*
+ * Assign a send side path_id to all paths.
+ */
static uint32_t
pathid_assign(struct rde_peer *peer, uint32_t path_id,
struct bgpd_addr *prefix, uint8_t prefixlen)
{
struct rib_entry *re;
- struct prefix *p = NULL;
uint32_t path_id_tx;
- /*
-* Assign a send side path_id to all paths.
-*/
+ /* If peer has no add-path use the per peer path_id */
+ if (!peer_has_add_path(peer, prefix->aid, CAPA_AP_RECV))
+ return peer->path_id_tx;
+
+ /* peer uses add-path, therefor new path_ids need to be assigned */
re = rib_get(rib_byid(RIB_ADJ_IN), prefix, prefixlen);
- if (re != NULL)
+ if (re != NULL) {
+ struct prefix *p;
+
p = prefix_bypeer(re, peer, path_id);
- if (p != NULL)
- path_id_tx = p->path_id_tx;
- else {
- do {
- /* assign new local path_id */
- path_id_tx = arc4random();
- } while (pathid_conflict(re, path_id_tx));
+ if (p != NULL)
+ return p->path_id_tx;
}
+
+ do {
+ /*
+* Assign new local path_id, must be an odd number.
+* Even numbers are used by the per peer path_id_tx.
+*/
+ path_id_tx = (arc4random() << 1) | 1;
+ } while (pathid_conflict(re, path_id_tx));
+
return path_id_tx;
}
Index: rde.h
===
RCS file: /cvs/src/usr.sbin/bgpd/rde.h,v
retrieving revision 1.271
diff -u -p -r1.271 rde.h
--- rde.h 12 Sep 2022 10:03:17 - 1.271
+++ rde.h 19 Sep 2022 15:15:12 -
@@ -99,6 +99,7 @@ struct rde_peer {
uint32_t remote_bgpid; /* host byte order! */
uint32_t up_nlricnt;
uint32_t up_wcnt;
+ uint32_t path_id_tx;
enum peer_state state;
enum export_type export_type;
uint16_t loc_rib_id;
Index: rde_peer.c
===
RCS file: /cvs/src/usr.sbin/bgpd/rde_peer.c,v
retrieving revision 1.23
diff -u -p -r1.23 rde_peer.c
--- rde_peer.c 1 Sep 2022 13:23:24 - 1.23
+++ rde_peer.c 19 Sep 2022 15:26:34 -
@@ -168,6 +168,22 @@ peer_add(uint32_t id, struct peer_config
peer->flags = peer->conf.flags;
SIMPLEQ_INIT(>imsg_queue);
+ /* assign random unique transmit path id */
+ do {
+ struct rde_peer *p;
+ int conflict = 0;
+
+ peer->path_id_tx = arc4random() << 1;
+ RB_FOREACH(p, peer_tree, ) {
+ if (p->path_id_tx == peer->path_id_tx) {
+ conflict = 1;
+ break;
+ }
+ }
+ if (!conflict)
+ break;
+ } while (1);
+
if (RB_INSERT(peer_tree, , peer) != NULL)
fatalx("rde peer table corrupted");
ypldap client cert authentication
This adds client certificate authentication to ypldap(8). libtls makes the
actual certificate part of this straightforward (I would still like it
reviewed, though), but there are some LDAP complications.
Depending on your LDAP server and how you connect to it (LDAPS on port 636
or LDAP+TLS on port 389), a client presenting a certificate might
automatically be bound as the subject of the certificate, or it might not.
If it's not, the client can do an LDAP bind operation using the SASL
EXTERNAL mechanism to bind as the cert subject, and it can optionally specify
an identity, which means the bind will fail if the cert subject doesn't match
that identity. If the client didn't present a certificate, the bind will
also fail (one would hope).
For reference, with Active Directory, SASL EXTERNAL bind is required when
using LDAP+TLS, but not when using LDAPS, and the client identity can be
specified in the form of "dn:" followed by the expected cert subject DN.
OpenLDAP doesn't seem to do automatic bind at all, so SASL EXTERNAL would
always be required there, and it doesn't appear to support specifying the
expected identity with the bind.
The diff adds 'certfile' and 'keyfile' config directives for specifying
the certificate to use, and a 'bindext' directive for enabling SASL EXTERNAL
bind, optionally including the identity string. SASL EXTERNAL bind doesn't
get enabled implicitly when you configure a client cert, because ypldap
can't tell if it's required or supported by the server. It's also not an
error to enable SASL EXTERNAL bind without a client cert, since you could be
connecting through stunnel or something.
To configure this in ypldap.conf, you'd do something like this:
directory "ldap.example.com" tls {
bindext "dn:CN=ypldap,OU,Accounts,DC=example,DC=com"
certfile "/etc/ssl/ypldap-cert.pem"
keyfile "/etc/ssl/private/ypldap-key.pem"
...
}
ok?
Index: aldap.c
===
RCS file: /cvs/src/usr.sbin/ypldap/aldap.c,v
retrieving revision 1.48
diff -u -p -r1.48 aldap.c
--- aldap.c 31 Mar 2022 09:06:55 - 1.48
+++ aldap.c 19 Sep 2022 11:47:13 -
@@ -220,6 +220,40 @@ fail:
}
int
+aldap_bind_sasl_external(struct aldap *ldap, char *bindid)
+{
+ struct ber_element *root = NULL, *elm;
+
+ if ((root = ober_add_sequence(NULL)) == NULL)
+ goto fail;
+
+ elm = ober_printf_elements(root, "d{tds{ts", ++ldap->msgid,
+ BER_CLASS_APP, LDAP_REQ_BIND, VERSION, "",
+ BER_CLASS_CONTEXT, LDAP_AUTH_SASL, LDAP_SASL_MECH_EXTERNAL);
+ if (bindid == NULL)
+ elm = ober_add_null(elm);
+ else
+ elm = ober_add_string(elm, bindid);
+
+ if (elm == NULL)
+ goto fail;
+
+ LDAP_DEBUG("aldap_bind_sasl_external", root);
+
+ if (aldap_send(ldap, root) == -1) {
+ root = NULL;
+ goto fail;
+ }
+ return (ldap->msgid);
+fail:
+ if (root != NULL)
+ ober_free_elements(root);
+
+ ldap->err = ALDAP_ERR_OPERATION_FAILED;
+ return (-1);
+}
+
+int
aldap_unbind(struct aldap *ldap)
{
struct ber_element *root = NULL, *elm;
Index: aldap.h
===
RCS file: /cvs/src/usr.sbin/ypldap/aldap.h,v
retrieving revision 1.14
diff -u -p -r1.14 aldap.h
--- aldap.h 11 May 2019 17:46:02 - 1.14
+++ aldap.h 19 Sep 2022 11:47:13 -
@@ -32,6 +32,8 @@
#define LDAP_PAGED_OID "1.2.840.113556.1.4.319"
#define LDAP_STARTTLS_OID "1.3.6.1.4.1.1466.20037"
+#define LDAP_SASL_MECH_EXTERNAL"EXTERNAL"
+
struct aldap {
#define ALDAP_ERR_SUCCESS 0
#define ALDAP_ERR_PARSER_ERROR 1
@@ -137,6 +139,7 @@ enum deref_aliases {
enum authentication_choice {
LDAP_AUTH_SIMPLE= 0,
+ LDAP_AUTH_SASL = 3,
};
enum scope {
@@ -222,6 +225,7 @@ void aldap_freemsg(struct
aldap_messa
int aldap_req_starttls(struct aldap *);
int aldap_bind(struct aldap *, char *, char *);
+int aldap_bind_sasl_external(struct aldap *, char *);
int aldap_unbind(struct aldap *);
int aldap_search(struct aldap *, char *, enum scope, char *, char **, int,
int, int, struct aldap_page_control *);
int aldap_get_errno(struct aldap *, const char **);
Index: ldapclient.c
===
RCS file: /cvs/src/usr.sbin/ypldap/ldapclient.c,v
retrieving revision 1.45
diff -u -p -r1.45 ldapclient.c
--- ldapclient.c22 Aug 2022 10:10:59 - 1.45
+++ ldapclient.c19 Sep 2022 11:47:13 -
@@ -635,7 +635,11 @@ client_try_idm(struct env *env, struct i
int rc;
where = "binding";
- if (aldap_bind(al, idm->idm_binddn, idm->idm_bindcred) == -1)
+ if (idm->idm_bindext !=
Re: wsmouse(4): Apple-like multi-touch buttons
Is there enough interest in this feature among OpenBSD users? I haven't
seen many requests for it, if any. Moreover, is it a good idea to configure
different input methods on this or that hardware just because another OS
has different defaults?
Just in case the answer to these questions turns out to be "yes", here are
some remarks on the diff.
First, I think the initialization bug should be fixed at its origin.
Currently, passing parameters to wsmouse_configure() only works with the
general wsmouse parameters (WSMOUSECFG_DX_SCALE .. WSMOUSECFG_REVERSE_
SCROLLING), and a subset of the touchpad-specific ones. Changing
wsmouse.c as follows will make it work with all of them:
diff --git a/sys/dev/wscons/wsmouse.c b/sys/dev/wscons/wsmouse.c
index c786af18208..0feae6824bb 100644
--- a/sys/dev/wscons/wsmouse.c
+++ b/sys/dev/wscons/wsmouse.c
@@ -1662,11 +1662,11 @@ wsmouse_configure(struct device *sc,
"Initialization failed.\n");
return (-1);
}
+ input->flags |= CONFIGURED;
if (params != NULL) {
if ((error = wsmouse_set_params(sc, params, nparams)))
return (error);
}
- input->flags |= CONFIGURED;
}
if (IS_TOUCHPAD(input))
wsmouse_set_mode(sc, WSMOUSE_COMPAT);
(We might as well remove the 'params' arguments from wsmouse_configure, and
leave the call to wsmouse_set_params() to the hardware drivers; up to now,
only pms changes default configurations.)
Two more remarks are inline.
On 9/18/22 16:42, Tobias Heider wrote:
> On Sun, Sep 18, 2022 at 02:21:06PM +0200, Tobias Heider wrote:
>> Hi,
>>
>> the diff below adds a new mouse type WSMOUSE_TYPE_APPLE which emulates Apples
>> touchpad behaviour. Instead of mapping soft-buttons to an area on the pad,
>> the different mouse buttons are mapped to single-finger, two-finger and
>> three-finger clicks as is the default in macos.
>>
>> The diff enables the new mode on apldcms(4) and aplms(4) which are the
>> drivers
>> used by Apple silicon laptops.
>>
>> Tested on an m2 air by me and an m1 by robert@.
>>
>> ok?
>
> Here's an updated version that does not add a new WSMOUSE_TYPE and as such
> does
> not require any changes in X. Instead I just pass the button configuration
> via
> params in wsmouse_configure().
>
> To make this work I had to fix a bug in wstpad where the CONFIGURE flag is not
> set after initial configuration, which causes all values to be overwritten
> with
> the defaults on each reconfigure triggered from wsmouse_set_params().
>
> diff --git sys/arch/arm64/dev/apldc.c sys/arch/arm64/dev/apldc.c
> index 09a03c734da..7962a3c645a 100644
> --- sys/arch/arm64/dev/apldc.c
> +++ sys/arch/arm64/dev/apldc.c
> @@ -1317,6 +1317,11 @@ const struct wsmouse_accessops apldcms_accessops = {
> .ioctl = apldcms_ioctl,
> };
>
> +static struct wsmouse_param apldcms_params[] = {
> + { WSMOUSECFG_SOFTBUTTONS, 0 },
> + { WSMOUSECFG_MTBUTTONS, 1 },
> +};
> +
> int apldcms_match(struct device *, void *, void *);
> void apldcms_attach(struct device *, struct device *, void *);
>
> @@ -1372,7 +1377,7 @@ apldcms_configure(struct apldcms_softc *sc)
> hw->mt_slots = UBCMTP_MAX_FINGERS;
> hw->flags = WSMOUSEHW_MT_TRACKING;
>
> - return wsmouse_configure(sc->sc_wsmousedev, NULL, 0);
> + return wsmouse_configure(sc->sc_wsmousedev, apldcms_params, 2);
> }
>
> void
> diff --git sys/arch/arm64/dev/aplhidev.c sys/arch/arm64/dev/aplhidev.c
> index 2b00f7e217d..ecfb5b8f4eb 100644
> --- sys/arch/arm64/dev/aplhidev.c
> +++ sys/arch/arm64/dev/aplhidev.c
> @@ -608,6 +608,11 @@ const struct wsmouse_accessops aplms_accessops = {
> .ioctl = aplms_ioctl,
> };
>
> +static struct wsmouse_param aplms_params[] = {
> + { WSMOUSECFG_SOFTBUTTONS, 0 },
> + { WSMOUSECFG_MTBUTTONS, 1 },
> +};
> +
> int aplms_match(struct device *, void *, void *);
> void aplms_attach(struct device *, struct device *, void *);
>
> @@ -663,7 +668,7 @@ aplms_configure(struct aplms_softc *sc)
> hw->mt_slots = UBCMTP_MAX_FINGERS;
> hw->flags = WSMOUSEHW_MT_TRACKING;
>
> - return wsmouse_configure(sc->sc_wsmousedev, NULL, 0);
> + return wsmouse_configure(sc->sc_wsmousedev, aplms_params, 2);
> }
>
> void
> diff --git sys/dev/wscons/wsconsio.h sys/dev/wscons/wsconsio.h
> index de483493360..497e9a32db7 100644
> --- sys/dev/wscons/wsconsio.h
> +++ sys/dev/wscons/wsconsio.h
> @@ -313,6 +313,7 @@ enum wsmousecfg {
> WSMOUSECFG_SOFTBUTTONS = 64,/* 2 soft-buttons at the bottom edge */
> WSMOUSECFG_SOFTMBTN,/* add a middle-button area */
> WSMOUSECFG_TOPBUTTONS, /* 3 soft-buttons at the top edge */
> + WSMOUSECFG_MTBUTTONS, /* multi-finger buttons */
Even though it requires updating a line of wsconsctl code, I think the
MTBUTTONS entry should be placed at
