The installer has potential to break systems, this is a very bad way of installing this

[codingneko]

A setup script that runs random commands the user has no knowledge of is a VERY bad idea. Please release this as a standalone Docker container that can be reverse proxied to. This script just destroyed half the services I have hosted in my server. Good thing I have backups. Thinking somebody is going to rent a server to host just ONE service is a very unrealistic assumption to make.

I'll basically need to containerize your containers in a new Docker container, so now we have 2 layers of orchestrated containers for something that could be a single container.

[codingneko]

What's wrong:

• The docker image you have is OK and works, but it doesn't work on its own because I need to run a pdsadmin script that doesn't work unless I ran your installer.sh which there is no way I'm going to do on my host machine again because it already broke my other services once.
• The pdsadmin.sh file doesn't actually contain any scripts, so I can't see what the hell it's doing, instead, it temporarily downloads them, and then removes them (for whatever reason)
• The actual pds container is NOT part of this repository, so I can't containerise it however I want. Instead I have to contianerise your container so it doesn't blow up my machine, which is hard because you're using FUCKING SYSTEMD to manage a DOCKER CONTIANER WHAT THE FUCK WHY?

Here is how to fix this issue:

• Post the actual PDS code, not a stub that pulls stuff from 30 different places.
• Include a Dockerfile that runs code in your repository. Not off an npm library elsewhere.
• (Optional) Include a docker-compose.yaml file that runs your container in the host docker. The service is not needed as docker will already start the containers on start up because you already have "restart: unless-stopped" on your compose.yaml
• (Optional) Include an install script that can O P T I O N A L L Y!!!! Be used to automatically install docker and start the containers.

[pfaffman]

Creating an install script that someone who knows nothing can use is hard, and by necessity makes some decisions that people who know anything at all consider very bad. A bunch of stuff is required to make this work, a reverse proxy, certs, so the fact that this works is admirable.

Watchtower, which this uses, pretty much explicitly says that you're a fool to use it in anything resembling a production setup:
[quote]
Watchtower is intended to be used in homelabs, media centers, local dev environments, and similar. We do not recommend using Watchtower in a commercial or production environment.
[/quote]

So if you know what you're doing, this isn't for you, but perhaps someone could spend a few minutes to create a howto guide for people who do know something.

Looks like you can just build a pds.env and crank it up like this:

  pds:
    container_name: pds
    image: ghcr.io/bluesky-social/pds:0.4
    network_mode: host
    restart: unless-stopped
    volumes:
      - type: bind
        source: /pds
        target: /pds
    env_file:
      - /pds/pds.env

You'll need to build a pds.env It's not clear to me if the Right Thing happens on the first run so that the sqlite databases get created, but glancing at the install script, it looks like it must.

[codingneko]

Creating an install script that someone who knows nothing can use is hard, and by necessity makes some decisions that people who know anything at all consider very bad. A bunch of stuff is required to make this work, a reverse proxy, certs, so the fact that this works is admirable.

Watchtower, which this uses, pretty much explicitly says that you're a fool to use it in anything resembling a production setup: [quote] Watchtower is intended to be used in homelabs, media centers, local dev environments, and similar. We do not recommend using Watchtower in a commercial or production environment. [/quote]

So if you know what you're doing, this isn't for you, but perhaps someone could spend a few minutes to create a howto guide for people who do know something.

Looks like you can just build a pds.env and crank it up like this:

  pds:
    container_name: pds
    image: ghcr.io/bluesky-social/pds:0.4
    network_mode: host
    restart: unless-stopped
    volumes:
      - type: bind
        source: /pds
        target: /pds
    env_file:
      - /pds/pds.env

You'll need to build a pds.env It's not clear to me if the Right Thing happens on the first run so that the sqlite databases get created, but glancing at the install script, it looks like it must.

Hey @pfaffman, thanks for the reply, I don't think your docker compose file will work (I tried making something very similar in my testing), mostly because even if it did, you're not going to get the util scripts their thing installs (pdsadmin), and since they're scattered all over the place, instead of being in a single .sh file (or multiple, local ones), you can't really recreate it locally.

Also the Nginx configuration for this thing to work is a nightmare, I have no idea what they require exactly (because they don't say anywhere), but I even created a KVM just to host this stupid thing, and set up a reverse proxy to point my pds url to it, and even forwarding ALL headers and everything, it literally just doesn't work.

I can log in, I can chat (bidirectionally), I can be followed by users, but I can't do literally anything else, can't follow users, can't post, can't create lists, can't do literally jack shid.

[LinuxDragon57]

I agree that this installation method is very bad. The installer script should not be a substitute for good documenation on installing the PDS. Personally, I prefer using Podman on a rootless user account because it is a more secure containerization setup, and the lack of adequate documentation makes this more difficult to accomplish. The website introduces the PDS with the following language:

Bluesky is an open network where you can choose your hosting provider. If you're a developer, you can host your own server. Learn more.

It seems to target this way of using the platform towards "developers", which begs the question: who does this organization define as a developer. Creating an install script that someone who knows nothing is indeed hard, and it's also more effort than it's worth, in my opinion. I think that that time would be better spent on creating actual documentation. Hosting the PDS shouldn't be targeted towards someone who knows nothing. It should be targeted towards people who already have experience in Linux system administration; or, at the very least, it should be targeted towards someone who is willing and able to learn how to do the actual work themselves instead of running a dubious script that performs a ton of actions, as root, on a platform that is likely completely foreign to them.

[LinuxDragon57]

Also the Nginx configuration for this thing to work is a nightmare, I have no idea what they require exactly (because they don't say anywhere), but I even created a KVM just to host this stupid thing, and set up a reverse proxy to point my pds url to it, and even forwarding ALL headers and everything, it literally just doesn't work.

Yeah. This is a huge problem. They seem to be working against people who don't want to do it their way, which is arguably incredibly insecure. Setting this up with a reverse proxy is going to be a nighmare.

[ledlamp]

They should provide manual setup instructions cause it's actually very simple and it's better for admins to understand what they are actually doing. This is basically all there is to it:

1. Set up env file (reference install.sh for key gen)
2. docker run -d --name=pds --restart=unless-stopped -v "./data:/pds" --env-file=env -p 127.0.0.1:3065:3000 ghcr.io/bluesky-social/pds:latest
3. Connect caddy (which I already have)
4. Download pdsadmin.sh, you just need to set PDS_ENV_FILE variable if it's not at /pds/pds.env (I put export PDS_ENV_FILE=./env in the script)

That's how I did it, I update it manually, you could add watchtower as well, you could use compose, or docker run in shell scripts practically the same 🙂

Of course any experienced admin can easily check the install.sh and figure it out in no time but a detailed walkthrough is important for teaching novice admins who need to learn how to maintain their system.

Also yea who TF controls their docker services with a systemd service?!?! Makes it even more convoluted and confuses ppl... systemctl restart pds? docker restart pds? cd /pds; docker compose restart pds? -.- Totally unnecessary, let docker do its thing with restart policy, KISS

[ledlamp]

• The docker image you have is OK and works, but it doesn't work on its own because I need to run a pdsadmin script that doesn't work unless I ran your installer.sh which there is no way I'm going to do on my host machine again because it already broke my other services once.

It works, you just need to set PDS_ENV_FILE if it's not at /pds/pds.env. It connects to the public https URL so you need to have your reverse proxy set up first.

The script downloading and running directly from github is really weird though yeah. Why TF they do that? They should just compile it all into one script.

• The actual pds container is NOT part of this repository, so I can't containerise it however I want. Instead I have to contianerise your container so it doesn't blow up my machine,

What do you mean? This repository has the Dockerfile so you can customize and build it however you want. Why do you need to put it in another container?

• Post the actual PDS code, not a stub that pulls stuff from 30 different places.
• Include a Dockerfile that runs code in your repository. Not off an npm library elsewhere.

They put everything in https://github.com/bluesky-social/atproto because there is a lot of common code that depends on each other and it is easier to develop this way. But putting all the PDS code in this repository would've made it easier to fork and modify

[ledlamp]

Also the Nginx configuration for this thing to work is a nightmare, I have no idea what they require exactly (because they don't say anywhere), but I even created a KVM just to host this stupid thing, and set up a reverse proxy to point my pds url to it, and even forwarding ALL headers and everything, it literally just doesn't work.

The PDS requires WebSockets which is a bit of a faf to set up nginx for. You have to do this crap...

http {
        map $http_upgrade $connection_upgrade {
                default upgrade;
                ''      close;
        }
...

proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;

Also don't forget to add

proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Proto $scheme;