From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mail.toke.dk; dkim=pass header.d=webweaving.org header.i=@webweaving.org header.a=rsa-sha256 header.s=shared header.b=IkZhAiPX; arc=none (Message is not ARC signed); dmarc=pass (Used From Domain Record) header.from=webweaving.org policy.dmarc=none Received: from weser.webweaving.org (weser.webweaving.org [148.251.234.232]) by mail.toke.dk (Postfix) with ESMTPS id 4EDBA197DD9C for ; Mon, 02 Nov 2026 13:13:34 +0100 (CET) Received: from smtpclient.apple ([10.11.0.230]) (authenticated bits=0) by weser.webweaving.org (8.18.2/8.18.1) with ESMTPSA id 6A2CDVF5065296 (version=TLSv1.2 cipher=ECDHE-ECDSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 2 Nov 2026 13:13:31 +0100 (CET) (envelope-from dirkx@webweaving.org) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=webweaving.org; s=shared; t=1793621612; bh=N7sxaHBzFUkD4upAkRgxoQEDbCFrbbQ7Fe4KsBdggKg=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=IkZhAiPXr+K2eaGHvwMqCNy9JMsXDnk7YxQ0Wsl4Ep88oBFOh8wa4q4a48nqa4cFx J+k67qn1Yb3VSbhMySo3Lzk2XlhUXu3YyGo1xnRCr5a9n9IFOX1mJPIBUtwU1R92FZ lO6IZ1hYu/FhiBoNdiVblCAW7HepfmgQwlqTt/lw= X-Authentication-Warning: weser.webweaving.org: Host [10.11.0.230] claimed to be smtpclient.apple Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.700.51.1.3\)) From: Dirk-Willem van Gulik In-Reply-To: <87jymvcubk.wl-jch@irif.fr> Date: Mon, 2 Nov 2026 13:13:28 +0100 Cc: galene@lists.galene.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <362CEC86-2063-4E6F-A30A-5C0AEABB5FF9@webweaving.org> <87jymvcubk.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3864.700.51.1.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.4 (weser.webweaving.org [148.251.234.232]); Mon, 02 Nov 2026 13:13:32 +0100 (CET) Message-ID-Hash: JONXYFBHH5WVEUHMQXKBKKGF2YIIYM7T X-Message-ID-Hash: JONXYFBHH5WVEUHMQXKBKKGF2YIIYM7T X-MailFrom: dirkx@webweaving.org X-Mailman-Rule-Hits: member-moderation X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency X-Mailman-Version: 3.3.10 Precedence: list Subject: [Galene] Re: wildcard users List-Id: =?utf-8?q?Gal=C3=A8ne_videoconferencing_server_discussion_list?= Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On 2 Nov 2026, at 13:05, Juliusz Chroboczek wrote: >> // Generated 2026-11-02 11:09:23 UTC, project bar-test, DB: = 9656dfdac01ba854402ca635e >=20 > You're mixing the old syntax (deprecated with Galene 0.9 in May 2024) = with Ah clear - yes - we've been using this for quite a while now. > the new syntax. You have a wildcard user in the new syntax: >=20 >> "wildcard-user": { >> "password": "", "permissions": "present" >> }, >=20 > and one in the old syntax: >=20 >> "presenter": [ >> {} >> ] >=20 > Since Galene will convert the old syntax to the new one internally, = you > end up with a duplicate wildcard user. >=20 > The simplest way to convert the group is to update the group using the > API, Galene will rewrite the group in the new syntax. I did >=20 > echo '{}' | galenectl update-group -group bolduc -jso Ah - that is neat - did not know we could do that. > which yielded >=20 > { > "users": { > "XXXXmoderator1XXX": {"permissions": "present"}, > "XXXXmoderator2XXX": {"permissions": "present"}, > "xxxchairpersonxxx": { > "password": {"type": "bcrypt","key": "XXX"}, > "permissions": "op" > } > }, > "wildcard-user": {"password": "","permissions": "present"} > } >=20 > Note that the two moderators have no password, they cannot login until = you > set a password. (This was not possible in the old syntax, which = interpreted > a lack of a password as a wildcard.) >=20 > I then did >=20 > galenectl set-password -group bolduc -wildcard -type wildcard >=20 > which yielded >=20 > { > ... > = wildcard-user":{"password":{"type":"wildcard"},"permissions":"present"} > } >=20 > (The difference between an empty password and a password of type = wildcard > is that the latter allows any password.) Clear. And clear how to set it - we never quite got that from the = documentation - apologies. >> And what is the right way to allow arbitrary names (and an empty or >> fixed, simple PIN style, password for ad-hoc cases where sending an >> invite or similar hurdle/extra step is non ideal) ? >=20 > Both of your syntaxes are correct, you should use one or the other, = just > not both. Clear - thanks - and that indeed fixed it. Working now perfectly without = warnings. > Another note: since you're generating passwords automatically, you may > consider going through the API rather than editing files on disk. = Editing > files on disk is still supported, but of course it doesn't guarantee > mutual exclusion if two programs edit the same file at the same time. > You'll find race-free code to do that here: >=20 > - in Go: galenectl/galenectl.go starting at line 470; > - in JS: static/management.js. I think we are a bit addicted to generating data configuration files at = the same time as we are standing up our (freebsd-jailed) ad-hoc = environments - as that is much easier to fit into our automation/IDS-es = which is fairly limited in terms of what networking it can do, generally = has no shell/exec()ability and currently lacks third party tools such as = galenectl. But i guess we're the odd one out. So thanks for that clear direction of travel clear - will look if we can = still somehow use the API in lieu of the files (or use the APIs to = generate the files in an isolated instance). With kind regards, Dw.=