From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 29185 invoked from network); 2 Nov 2022 19:20:08 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 2 Nov 2022 19:20:08 -0000 Received: from mail-pj1-f44.google.com ([209.85.216.44]) by 9front; Wed Nov 2 15:18:22 -0400 2022 Received: by mail-pj1-f44.google.com with SMTP id d59-20020a17090a6f4100b00213202d77e1so3043771pjk.2 for <9front@9front.org>; Wed, 02 Nov 2022 12:18:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nzm-ca.20210112.gappssmtp.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=u+oLN7OzkumblhB/BLDp4imH4hQnQLI8fCIHCfrEWk4=; b=6PMOLeRd+RKffxeYQUBrHGjeCLhH4WPCFJ1dRB3WZH3ixQrHVlYk0uhW7037zDoch3 8FuwxRELp4ll1gTejT8JCS6loOPq2PpC+TOo6Fzttra492nG4WkrOCmehqLTi077+4Sl pXR/oBPMh2dFX6S+6EwcXnKFACBaRXuvmIY6uTba0ronl0ikQbpFtnvaEGZtppG9x1RK dDHGq9llOyM7Sx9HvZyRHR8xP/Rw3oRgpcx+Gzx08cvEyOFPcjEZovYlpVFwRb266X+s 2K3Ez8ZNqb4dbQTF8tjMJhY6/ZadCp30z9YBQ+LHEHKwoKN8eTOoSaKN39ihSEAd8+d8 WTmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=u+oLN7OzkumblhB/BLDp4imH4hQnQLI8fCIHCfrEWk4=; b=bh4YDjnGJkdRGYqigqkf19A5/JU8xiDQ8jggsP1EIWpTjVdj958SZSHuXnoEmGolGn I/nQ+amyiVe86qPyva4MbXOZvaUVO+Lb57MQ7Gk69E8DWA0I+A/qhO+VvwmoKL7/LtZf Vyts8BxZ5SzA/BSo8tgXC6dG+esAW1mSEAHtsByUTLla9Hdt8fW26cAom6N48Y0k7N+r cJ9fpRU/5JxEZgaR2DJGGYIiFGB1kp3P9zq4gKSNIS5/igvZ4nuKyIZ2k+UzIWacrc0d Xf/Ymlnf4SkcLZH71Qot5cDbhNG6uCUxCfbrfdkSTv3hLV4yjwWQRAHs6Z25NK0MtaAa nITg== X-Gm-Message-State: ACrzQf2SGPXlG/qscygnMHeD6goulexx62My4g/nv4DLch84vF84OEsa /cUEiUOE42hIifa5SeAEZn+W0u3Ua3+NQBBgebWqREPiKJU= X-Google-Smtp-Source: AMsMyM7kUtiyZX0UI9qxpfXgcYyAYR1zg2Rw/Hz2k7Mof/3WDVmRk6akYbvB8dtUdV1ZV0NjbAOuf12kLe3228e0Wl4= X-Received: by 2002:a17:902:8346:b0:178:a33f:89cf with SMTP id z6-20020a170902834600b00178a33f89cfmr26050462pln.9.1667416695561; Wed, 02 Nov 2022 12:18:15 -0700 (PDT) MIME-Version: 1.0 From: Nathan Zimmen-Myers Date: Wed, 2 Nov 2022 15:18:04 -0400 Message-ID: To: 9front@9front.org Content-Type: text/plain; charset="UTF-8" List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: cloud injection interface Subject: [9front] Two file servers sharing an auth server Reply-To: 9front@9front.org Precedence: bulk Hello all, I'm still somewhat new to getting 9 set up in a distributed way, and am struggling to have two separate fileservers sharing an auth server. Firstly, I want to confirm that this is feasible and (relatively) common. If this is uncommon/incorrect, is it preferable to maintain localized documents on a non-OS drive, while booting from an auth server? The initial goal that I had started with, was to have a web server installation that boots from disk, but obtains authentication information from an authentication server with which it does not share a disk. To illustrate: fs1 hosts auth with its own fileserver, currently nothing else. web1 hosts a fileserver and will host an httpd. These VPSs are both hosted in the same Vultr datacenter, so the latency between them is minimal. As ori mentioned in IRC, keyfs is used to maintain the authentication database which can be queried remotely (I believe? this might not be a correct interpretation), is it correct to simply mount keyfs on web1 from fs1? The other option which comes to mind, is to boot web1 from fs1, and use web1's disk for documents to be connected to httpd, which may make long-term maintenance easier. Would this be a more common configuration? My assumption is that web1 should not get all of its web documents from fs1, as this would duplicate traffic - and I am happy if I am wrong. Thanks all! nzm