• 1 Post
  • 90 Comments
Joined 2 years ago
cake
Cake day: June 13th, 2023

help-circle












  • I’d like to see some documentation that says passkeys were intended to never be synced across anything.

    Everything I have ever read is that it’s basically asymmetric cryptography like ssh keys. You have a private one, generate the public and give it to the site. It stops reuse of passwords and site breaches become useless as the public key is useless for attacking an account on another site, etc. (well, besides whatever data was lost in the breach which is outside the scope.)

    I see no reason to limit someone having the private key on their phone, their desktop, etc. Having to generate yet another passkey for every device is inefficient and would decrease adoption of this.



  • I distinctly remember yum/dnf should be using a loop. Forget why but it’s recommended. Here’s a snippet from my playbook. Simply make the vars as you need and run.

      - name: Install flathub as remote
        ansible.builtin.shell:
          cmd: flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo
        tags:
          - apps
    
      - name: Install flatpak apps
        community.general.flatpak:
          name: "{{ item }}"
          state: present
        loop: "{{ flatpaks }}"
        tags:
          - apps
    
      - name: Remove some default unused packages
        ansible.builtin.dnf:
          name: "{{ item }}"
          state: absent
          update_cache: no
        loop: "{{ remove }}"
        ignore_errors: true
        tags:
          - apps
    
      - name: Install our packages
        ansible.builtin.dnf:
          name: "{{ item }}"
          state: present
          update_cache: yes
        loop: "{{ rpms }}"
        ignore_errors: true
        tags:
          - apps```
    
    On mobile. Apologies if formatting is off.


  • Exactly. I don’t know if the AIO image was used and how that all works (I stay away from that and the snap which is just an abomination) but no one should try to selfhost anything for prod unless they know exactly how it works. That and have a staging env. If you’re not up to the task then just pay for some commercial hosting (even if it’s just Nextcloud that is hosted elsewhere.)

    I’ve run the nextcloud image (just docker.io/nextcloud IIRC) pinned for years with k8s and it’s durable and fine. It stays put and I just take the time to update my testing instance, make sure it all works with some cheap smoke tests, then upgrade prod.