FYI - you're sharing links that use HTTP and require logging in. There are no redirects to HTTPS, so it's not the safest as credentials may be shared in plaintext. Also, not sure where you got universal.blue.discourse.group from - I believe it should be universal-blue.discourse.group
I've taken on a new role at my company focused on cybersecurity, so a login page on http is a major red flag. These now stand out much more than they did before
Iβm wondering if/where I or we could document this https://github.com/ublue-os/bling/issues/77 somewhere. Itβs caused by having installed 1Password and/or its CLI via the RPM packages before β if you integrate 1Password into your ostree image via bling, but youβve ever installed the RPM packages on a deployment before, the GIDs wonβt match and itβll complain
I wrote a simple script that I put in a GitHub gist in the last comment that will renumber the groups to whatever they should. Like, maybe we could put it in some kind of FAQ or something?
In short, 1Password silently crashes if itβs integrated on your image and rpm-ostree deploys an update. I think whatβs going on is that 1Password thinks itβs being tampered with and panics/dies, because the destination of the /opt/1Password symlink gets shuffled around
but each one also has a thread of discussion so you could do all the "working session" stuff in the comments but the user just sees the final page. All you need to do is set your post to wiki
Fix for incorrect GIDs for onepassword and onepassword-cli groups on a custom image Symptoms (See also ublue-os/bling issue #77) Youβve integrated 1Password into your custom image, but its integration between the desktop application and either the browser extension or the op CLI donβt work. Also, the GID is wrong: $ ls -l /usr/bin/op -rwxr-sr...
could i ask you to fix the formatting for me (i put a closing ``` for my code fence on the same line as code) and convert it to a wiki post please @j0rge
Indeed it is, I wasn't sure of the right thred to post the question into, sorry. The problem I see is that I will likely end up posting the WiFi password and SSID into a public fork. (Though that's likely a problem either way)
It may be that editing the ISO post download to inject the Kickstart for a Root Password and WiFi details is the best way to go, without storing those details in the cloud. Maybe reworking this to prompt the user for input could be the safest way to go. https://github.com/alextrical/Fedora-Kinonite-Fablab-Kickstart
It's for deployment inside a Makerspace, so I'm hoping to minimise effort required to restore a working system. The problem is that it asks for the WiFi details after installing, but if the user doesn't enter them in Anaconda the install fails to fetch the built os, and as a result can't install the OS
That could work, they now have a Draytek router which allows up to 4 SSID's and we could set the last one to be enabled when re-provisioning. Though is there really that much danger having the Kickstart configured on a pendrive, when it's kept securely in the owners office drawer?
I suppose I'm aiming to do the equivalent of as close as possible to a preconfigured OS deployment. Back in the XP days, Sysprep was amazing for getting a monoculture of PC's setup identically with minimal input of the technicians. I'm hoping to make something as elegant as that for the Makerspace, Ideally, insert a USB key, reboot, select HDD to install to and select install. Once done ideally have WiFi, Admin and Kiosk user accounts created, all the software installed and configured ready to go, including connection to the central owncloud file share
Once the tooling lands the oci support that shouldn't be a problem. I was doing that at an edu with the full automation, automated pxe install, zero config other than turning the machine on. That was 2006, so it'll be at least that good, hahah.