bluesky-social / pds Goto Github PK

Here are the logs from the server, looks like it's using an older version of @atproto/pds

{"level":50,"time":1705423676962,"pid":7,"hostname":"553e991e2727","name":"xrpc-server","err":{"type":"InvalidRequestError","message":"Provided invite code not available","stack":"Error: Provided invite code not available\n    at ensureCodeIsAvailable (/app/node_modules/@atproto/pds/src/api/com/atproto/server/createAccount.ts:161:11)\n    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\n    at handler (/app/node_modules/@atproto/pds/src/api/com/atproto/server/createAccount.ts:39:9)\n    at <anonymous> (/app/node_modules/@atproto/xrpc-server/src/server.ts:254:35)","errorMessage":"Provided invite code not available","customErrorName":"InvalidInviteCode"},"msg":"error in xrpc method com.atproto.server.createAccount"}
{"level":30,"time":1705423677647,"pid":7,"hostname":"553e991e2727","name":"pds","req":{"id":28,"method":"POST","url":"/xrpc/com.atproto.server.createAccount","query":{},"params":{},"headers":{"x-real-ip":"","x-forwarded-for":"","host":"bluesky-pds:3000","connection":"close","content-length":"181","sec-ch-ua":"\"Not_A Brand\";v=\"8\", \"Chromium\";v=\"120\"","sec-ch-ua-platform":"\"macOS\"","sec-ch-ua-mobile":"?0","user-agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36","content-type":"application/json","accept":"*/*","origin":"https://bsky.app","sec-fetch-site":"cross-site","sec-fetch-mode":"cors","sec-fetch-dest":"empty","referer":"https://bsky.app/","accept-encoding":"gzip, deflate, br","accept-language":"en-US,en;q=0.9"}},"res":{"statusCode":400,"headers":{"x-powered-by":"Express","access-control-allow-origin":"*","content-type":"application/json; charset=utf-8","content-length":"76","etag":"W/\"4c-nTgSJZL7uNTt2++MFFo/NFWNNSU\"","vary":"Accept-Encoding"}},"responseTime":690,"msg":"request completed"}

Hello,

When trying to pull latest from pds, the following error occurs: Error response from daemon: manifest unknown

Step to reproduce:
sudo docker pull ghcr.io/bluesky-social/pds:latest

Regards,

Hello,

I was tinkering around, and I think I may have broken something for my account. I am running my own bluesky pds server, but had to switch from one host/ip to another after learning more on how it was deployed.

My flow was this:

1. install pds on server/ip-1 for domain test.com
2. go to https://bsky.app/ and log in to user account from test.com
3. uninstall pds on server/ip-1
4. change dns for *.test.com and test.com to server/ip-2
5. install pds on server/ip-2 for domain test.com

So I saw that there was the .env file in the /pds folder. I added SMTP from the env vars specified here: #44

I was able to email verify my account on the https://bsky.app/ site, then I deleted my account to see if I could reset and have things start fresh with server/ip-2.

So I made a new account through my pds server, and logged in again at https://bsky.app/ . However, it looks like my "DID" value seems to be saved somewhere on bsky's side, because I am getting errors posting, getting my profile, seeing lists, etc.

Perhaps I am being too fast to assume it would work after changing servers, is there a caching mechanism in place that will update the DID value for my account from my server from within bsky?

example error here:

👋 I did not see the backup and recovery section anywhere in the doc, did I miss anything? Thanks!

Hi.
Apologies if this has been addressed, but other than the "Invalid Handle" issue, which is not exactly my case, I couldn't find anything regarding this.

When trying to register a new account on a freshly installed PDS, for the sandbox, I get either a Too Short or Too Long error, even with a single character difference. I can't go past this screen using the web app.

I'm guessing there is actually something else going on under the hood but I've no idea where to look with this software. There doesn't seem to be any log stored under /pds ?

The PDS is responding fine to /xrpc/_health. I should mention it doesn't use Caddy as a reverse proxy but nginx (this is not negotiable, as I have other websites sharing the IP). The reverse proxy blindly forwards the requests so it shouldn't be interfering.

Version: 0.3.0-beta.3

Hello, I wanted to install Bluesky PDS on my server, but since port 3000 is already getting used for something else important, I tried changing the port from PDS, but I just can't find out how. Is it even possible?

In the Readme here, I see PDS defined as either Protocol data Service or Personal Data Server.
This is very confusing. If there are really two related but different things, they shouldn't share the same acronym. Furthermore, in the rest of the documentation for bluesky, the acronym should be defined when first used, e.g. https://docs.bsky.app/docs/starter-templates/custom-feeds.

Thanks!

the "containrrr/watchtower" gives me the following error:

Could not do a head request for "ghcr.io/bluesky-social/pds:latest", falling back to regular pull.
Reason: registry responded to head request with "404 Not Found", auth: "not present"
Unable to update container "/pds": Error response from daemon: manifest unknown. Proceeding to next.

if i try:
docker compose pull
i get this error:
Error response from daemon: manifest unknown

This is an example of the result when creating a new user to the PDS. I have some doubts about what is causing this or if we have to wait a bit to get rid of it.

The pdsadmin/account.sh create script appears to create accounts which always appear as "⚠️Invalid Handle ⚠️Invalid Handle" until you edit the profile and change the display name or bio. This is neither documented nor indicated by the account.sh tool.

I am mostly certain about this, I have seen it once in informal use and once in a controlled test I did this afternoon. Here are the steps I performed:

Repro

I have a functioning PDS server bsky.example.com. On the server, I run pdsadmin/account.sh. I give it email address [email protected] and handle temporary3.bsky.example.com. It gives me DID did:plc:ei24m7la7nsl656y3hmnideo and a password.

Next I go to my DNS configuration and I add a TXT record containing "did=did:plc:ei24m7la7nsl656y3hmnideo" to subdomain _atproto.temporary3.bsky. I use https://bsky-debug.app/handle?handle=temporary3.bsky.example.com to verify it's correct (it is).

In an incognito Firefox window, I go to bsky.app and click "log in". I select "custom server" bsky.example.com. I log in as temporary3.bsky.example.com. It lets me log in. I verify with https://plc.directory/did:plc:ei24m7la7nsl656y3hmnideo that my plc is registered correctly. It is.

I click "Profile". I see the screenshot above. I reload several times over several minutes. It continues saying this. I click "Edit Profile" and enter a display name and bio. Immediately it now shows my display name and handle.

Note: "example.com" is of course not my domain, you can see my real domain if you click plc.directory. (Although after running this test I tested changing usernames, so the username you will find on plc.directory is no longer "temporary3".) I have a log of everything journalctl printed during this test.

Expected behavior

Ideally, whatever step is necessary for a handle and username to be not "invalid" should be performed by the account.sh create step. But if this is inconvenient, or if changing the display name is really a required step for whatever reason, then the documentation (help.sh) should print that to make the plc usable you need to log in and change the displayname/bio once (or whatever the magic step is); and in my opinion account.sh create should also print this when it succeeds in creating an account.

Impact

In my testing, I find many different errors in PDS setup can result in a newly created account appearing as "⚠️Invalid Handle". However, in the case above, "⚠️Invalid Handle" is shown even though the PDS is fine. Since the documentation does not give adequate guidance about this final nonobvious step, someone setting up a new PDS would be misled to believe their PDS is misconfigured even once it actually is working.

Hello!
I hope all is well.

I've set up a pds on https://bsky.femtoAmpere.art/:

$curl https://bsky.femtoAmpere.art/xrpc/_health 
{"version":"0.2.0-beta.5"}

However, if I want to create an account in the sandbox using my invite code I get the following on https://bsky.app/:

Is this expected behaviour and I'm missing something big here? Is this an issue of https://bsky.app/? I am,

• using nginx reverse proxy instead of caddy.
• on a Debian Buster VPS:

$lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 10 (buster)
Release:        10
Codename:       buster

Thank yoou~

I currently have several data solutions operating at the root of my domain, including ActivityStreams / ActivityPub, Solid, and now ATP. The goal is to enable a reverse proxy to route to the appropriate service based on the request content (essentially URL pattern and headers).

Are there recommended methods of defining this separation to route requests to the PDS appropriately?

is their way we can search follow bsky users on our own pds?

Having issues cant see bsky users and @hockley.info on my pds and profile shows as blank like not their

end point showing PDS_BSKY_APP_VIEW_ENDPOINT=https://api.bsky-sandbox.dev

Watchtower is currently configured to update all containers on the host. But it should only update the containers specified in the compose file, since there may be unrelated containers on the host that would not be good to update automatically.

See: https://containrrr.dev/watchtower/container-selection/

I have deployed an instance of my own PDS. I am using bsky.app as a client. On settings there is a Verify My Email button, which I click but no email is received. Am I supposed to set up SMTP on the PDS or is the client's job?

Thanks!

Hello,

I was having issues with creating a new user, after deleting an old one with the same username / e-mail. After some troubleshooting I found out that, after deleting a user, the user gets removed from "user_account" but doesn't get deleted from "user_pref".
After deleting the user from "user_pref" I could use my @ again.

Following creating a PDS using automated install and inviting a user to test it out it you can't actually view the user's profile, or do any actions as said user. I am extremely inexperienced when it comes to Bluesky and the AT protocol, so if I'm missing something obvious please don't hesitate to say. Here are the log messages:
Error: Actor not found: linuxuser.[domain name]
Error: Error: Params must have the property "actor"
Error: Profile not found

I also noticed that my domain isn't listed in https://atscan.net/pds, if that is important.

I'm trying to run a PDS at bsky sandbox. Everything has gone smoothly until the moment to get an invite, when I get an auth error message:
{"error":"AuthenticationRequired","message":"Authentication Required"}

Steps to reproduce the behavior:

PDS_HOSTNAME="d-twitter.com"
PDS_ADMIN_PASSWORD="" ## I replace with the actual admin password

curl --silent
--show-error
--request POST
--user "admin:${PDS_ADMIN_PASSWORD}"
--header "Content-Type: application/json"
--data '{"useCount": 1}'
https://${PDS_HOSTNAME}/xrpc/com.atproto.server.createInviteCode

• Operating system: Ubuntu 22.04
• Node version: Not installed

With a fresh install of pds version 0.3.0-beta.3 on Ubuntu 22.04 using the installer script, after creating a new account, the Profile page shows "Page not found" but if I go to "settings" and change my handle, it starts working.

Since this morning I have been unable to connect to my sandbox PDS and when I checked Caddy's logs there were errors.

Error: loading initial config: loading new config: loading http app module: provision http: getting tls app: loading tls app module: provision tls: provisioning automation policy 0: on-demand TLS cannot be enabled without an 'ask' endpoint to prevent abuse; please refer to documentation for details

So I added to the Caddy file referring to the following post and it started working again
https://bsky.app/profile/ubanis.com/post/3k453hmbgfm2y (bsky.social Post)

{
        email my-email-address
        on_demand_tls {
                ask http://localhost:3000
        }
}

I'm sorry I don't know the details, but is it necessary to reflect this in install.sh?

Hello,

I'm going through the steps to host a PDS on my Vultr server and got to the point where I need to run the installer.sh file. However, the service related to the PDS refuses to start for some reason:

Is there some permission issue or something I'm missing here?

Hello,
my steup is with docker

nginx on dmz server<--> port 3000 of pds into internal network

I removed caddy:

version: '3.9'
services:
  pds:
    container_name: pds
    image: ghcr.io/bluesky-social/pds:latest
    network_mode: host
    restart: unless-stopped
    volumes:
      - type: bind
        source: /pds
        target: /pds
    env_file:
      - /pds/pds.env
  watchtower:
    container_name: watchtower
    image: containrrr/watchtower:latest
    network_mode: host
    volumes:
      - type: bind
        source: /var/run/docker.sock
        target: /var/run/docker.sock
    restart: unless-stopped
    environment:
      WATCHTOWER_CLEANUP: true
      WATCHTOWER_SCHEDULE: "@midnight"

So the nginx is reverse proxying to pds directly.

  upstream home {
    server 192.168.253.3:3000;
    keepalive 15;
  }

server {
    server_name home.REDACTED.eu;
    server_name *.home.REDACTED.eu;

    location / {
#      auth_basic "Restricted Access";
#      auth_basic_user_file /etc/nginx/htpasswd.users;

add_header                X-ECache 1;
  add_header                X-ECache-Key    $host$uri$is_args$args;
  add_header                X-ECache-Status $upstream_cache_status;
add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;";
  proxy_ignore_headers      "Expires";
  proxy_ignore_headers      "Cache-Control";

  proxy_cache_key           "$host$uri$is_args$args";
  proxy_cache_valid         200 1d;

      proxy_pass http://home;
      proxy_http_version 1.1;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection 'upgrade';
      proxy_set_header Host $host;
      proxy_cache_bypass $http_upgrade;    
      proxy_redirect off;
      proxy_buffering off;

      proxy_set_header Connection "Keep-Alive";
      proxy_set_header Proxy-Connection "Keep-Alive";
 client_max_body_size 10G;
client_body_buffer_size 400M;
    }
   listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/home.REDACTED.eu/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/home.REDACTED.eu/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
location /.well-known/carddav {
    return 301 $scheme://$host/remote.php/dav;
}

location /.well-known/caldav {
    return 301 $scheme://$host/remote.php/dav;
}
}
server {
    if ($host = home.REDACTED.eu) {
        return 301 https://$host$request_uri;
    } # managed by Certbot
    server_name home.REDACTED.eu;
    listen 80;
    return 404; # managed by Certbot
}

I used letsencrypt to generate a wildcard to *.home.REDACTED.eu

I can login, see profile and such, but my feed is empty.

Where am I mistaken?

Hello,

After a PDS reinstall (with a new handle, new subdomain, etc), it seems the profile isn't found, despite being able to validate the email address (got the confirmation code, etc).

No "handle error" issue, everything seems fine, I can access other peoples' feed etc, but can't:

• view my own profile
• post
• follow other users

I'm not sure how to debug this.

Regards,

As per title, please provide documentation for running the web interface in conjunction with the data server

Thanks

Title says it all. In the real world deployments, we are not limited to Caddy. Providing instructions on how to host behind nginx would be a great addition.

Not working when creating a ticket records set to *.

I'm reading through the code and documentation, and most of the dynamic nature seems to be around the authentication - not the actual serving of user data (besides the internal retrievals and real-time parsing, that is all negated when statically hosted as we process ahead of time).

I am proposing a READ ONLY structure to the PDS API. One that we could flush out with 100s of directories and index.html files in an S3 bucket or Github pages, that the network can just pull data from.

It's public data. There's no reason we should limiting access to it behind all of these PDS authentication protocols, as well as requiring unnecessary server-side processing in real-time.

Want an ECO angle? This is extremely wasteful for the planet, to process the same Public data over and over again, on each request. Processing authentication protocols for, again, public data. Static hosting has proven to reduce massive CPU processing in data centers (massive power usage drop, less switching processing of traffic) simply by parsing once ahead of time, and storing the Public json/html/js result to serve statically at a CDN. As the world explodes with PDS, this may be the time to cut the carbon footprint.

The goal? The ability for an end-user to setup a PDS to serve static content on the network. Like my BlueSky posts, and posting to my static blog.

I believe we should not have to setup a dedicated VM, just to serve static public content on these networks. A dynamic AppView? Absolutely for security and moderation. However, not the PDS static public data.

If I am missing a security angle, please elaborate and we can close the issue.

I've deployed my PDS on Render, which uses the Dockerfile in the repository. The Dockerfile doesn't include the pdsadmin.sh script by default. I had to manually pull it down in a shell. Even after that, the script doesn't run by default. First, I needed to install the following packages:

bash
curl
openssl
jq

I also needed to create a dummy text file at /pds/pds.env, even though all the environment variables were already set.

This happens to be a specialty of mine, and in my experience offers several advantages over Docker Compose setups. Would you be open to a PR to add the option?

After fresh installs of both Ubuntu 22.04 and Debian 12 and then running the install.sh script I'm getting internal SSL errors when trying to verify the health of PDS.

In Debian:

When I run:
curl https://[domain_redacted]/xrpc/_health
I'll get a 502 Error from Cloudflare reporting a SSL misconfiguration

If I go directly to the local IP address:
curl https://[ipaddress_redacted]/xrpc/_health
I get
OpenSSL/3.0.9: error:0A000438:SSL routines::tlsv1 alert internal error

In Ubuntu using wget or curl I have a similar experience. Example of the wget OpenSSL error:

--2023-09-22 00:19:44--  https://[ipaddress_redacted]/xrpc/_health
Connecting to [ipaddress_redacted]:443... connected.
OpenSSL: error:0A000438:SSL routines::tlsv1 alert internal error
Unable to establish SSL connection.

I'm running a reverse proxy, and when I point the domain to a different service on my network to make sure my DNS is configured properly, it works as expected.

This is my pds.env:

PDS_HOSTNAME=pds.[redacted].dev
PDS_JWT_SECRET=[redacted]
PDS_ADMIN_PASSWORD=[redacted]
PDS_REPO_SIGNING_KEY_K256_PRIVATE_KEY_HEX=[redacted]
PDS_PLC_ROTATION_KEY_K256_PRIVATE_KEY_HEX=[redacted]
PDS_DB_SQLITE_LOCATION=/pds/pds.sqlite
PDS_BLOBSTORE_DISK_LOCATION=/pds/blocks
PDS_DID_PLC_URL=https://plc.bsky-sandbox.dev
PDS_BSKY_APP_VIEW_ENDPOINT=https://api.bsky-sandbox.dev
PDS_BSKY_APP_VIEW_DID=did:web:api.bsky-sandbox.dev
PDS_CRAWLERS=https://bgs.bsky-sandbox.dev

This is my Caddyfile:

{
        email [redacted]@gmail.com
        on_demand_tls {
                ask http://localhost:3000
        }
}

*.pds.[domain_redacted].dev, pds.[domain_redacted].dev {
        tls {
                on_demand
        }
        reverse_proxy http://localhost:3000
}

I just found PDS today so I expect I'm missing something obvious in my configuration.

Has anyone else run into this?

When I start sandbox pds and create an account, the following log is output and account creation fails.
PDS is running with the DB relationship cleared.

Sep 30 23:15:52 i-50100000502679 node[260644]: {"level":50,"time":1696083352922,"pid":260644,"hostname":"i-50100000502679","name":"pds","req":{"id":4,"method":"POST","url":"/xrpc/com.atproto.server.createAccount","query":{},"params":{},"headers":{"host":"n.redocean.one","x-real-ip":"14.12.120.32","x-forwarded-for":"14.12.120.32","connection":"close","content-length":"120","content-type":"application/json","accept-encoding":"gzip","user-agent":"okhttp/4.9.2"}},"didKey":"did:key:zQ3shnKSeGZp3Kc1KPTYn55bKpdjw7cpvaZzyZErNqcW7i4EE","handle":"forza7.n.redocean.one","msg":"failed to create did:plc"}
Sep 30 23:15:55 i-50100000502679 node[260644]: {"level":50,"time":1696083352927,"pid":260644,"hostname":"i-50100000502679","name":"xrpc-server","err":{"type":"PlcClientError","message":"Request failed with status code 400","stack":"Error: Request failed with status code 400\n at Function.fromAxiosError (/home/sandbox-pds/node_modules/node_modules/.pnpm/@[email protected]/node_modules/@did-plc/lib/src/client.ts:160:12)\n at Client3.sendOperation (/home/sandbox-pds/node_modules/node_modules/.pnpm/@[email protected]/node_modules/@did-plc/lib/src/client.ts:66:28)\n at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\n at (/home/sandbox-pds/node_modules/@atproto/pds/src/api/com/atproto/server/createAccount.ts:78:13)\n at (/home/sandbox-pds/node_modules/@atproto/pds/src/db/index.ts:180:23)\n at (/home/sandbox-pds/node_modules/node_modules/.pnpm/[email protected]/node_modules/kysely/dist/esm/kysely.js:370:32)\n at DefaultConnectionProvider.provideConnection (/home/sandbox-pds/node_modules/node_modules/.pnpm/[email protected]/node_modules/kysely/dist/esm/driver/default-connection-provider.js:10:20)\n at Database.transaction (/home/sandbox-pds/node_modules/@atproto/pds/src/db/index.ts:175:30)\n at handler (/home/sandbox-pds/node_modules/@atproto/pds/src/api/com/atproto/server/createAccount.ts:49:22)\n at (/home/sandbox-pds/node_modules/@atproto/xrpc-server/src/server.ts:254:35)","status":400,"data":{"type":"Object","message":"Operations not correctly ordered","stack":""}},"msg":"unhandled exception in xrpc method com.atproto.server.createAccount"}

hello.

I am trying to create pds and try various things.

I know how to use the s3 bucket, but I ask because there seems to be no way to change the endpoint.

I'm currently using cloudflare r2, not aws s3.

Subdomains work but main domain dont work PDS please fix this bug Invailed Handle @Libertywave.app Cant Resolve Host issue keeps happing been on going for ages subdomain works only PDs

I want to host pds at kubernetes.

The sandbox has started to not register new posts and now it just sometimes allows you to like and repost, but only sometimes.
I've tested on two different PDSes and the same thing happens.
Mostly opening this issue on here because I don't know where else to put this.

Have self hosted a PDS for testing and when trying to validate DNS TXT record to change handle to domain, the client just pulls the first and oldest TXT record and fails verification.

dig TXT _atproto.domain.foo pulls the expected TXT record, so don't know why verification isn't working.

Is the TXT record cached somewhere and if so, how do I reset it pds side?

Thanks.

Describe the bug

Properly created accounts on PDS are failing on Bsky.app as

Not Found
Profile not found

Despite being signed in successfully

To Reproduce

1. create new PDS
2. create one or two users on PDS
3. log into bsky.spp with the account handle and ads from the ads
4. attempt to access profile, etc.

Expected behavior

I would expect that the new user would be able to access the profile and settings and be fully valid and usable.

Screenshots

Details

• Platform: macOS Sonoma Firefox, Safari, Edge
• Platform version: Version 14.3.1 (23D60
• App version: Web

Additional context

There is a fully valid and working user that has the domain as a handle on the account.

Please document how to use all option that can be set using env: https://github.com/bluesky-social/atproto/blob/main/packages/pds/src/config/env.ts

Repro

Say I have just set up my new PDS server bsky.example.com. The first thing I want to do is create a user account for testing. I see that I can use the script pdsadmin/account.sh in this repo to create an account. So I run:

$ bash ../pdsadmin/account.sh create
Enter an email address (e.g. [email protected]): [email protected]
Enter a handle (e.g. alice.bsky.example.com): test.bsky.example.com
ERROR: Reserved handle
Usage: ../pdsadmin/account.sh create <EMAIL> <HANDLE>

"test" is on a list of reserved handles built into the atproto source code. Fair enough. But there is a problem: This is the administrator interface. In theory, I am the exact person these handles are being "reserved" for.

This is especially inconvenient in the case of the prepackaged docker container, where there is no straightforward access to the source (to, for example, remove items from the reserved list).

"Expected behavior"

admin.sh create should support an --override flag. /xrpc/com.atproto.server.createAccount should have some way to verify the caller is an administrator and should be allowed to bypass the usual rules about what is a legal handle; since admin.sh has access to .env and therefore the admin password, it should be able to perform this verification automatically when --override is passed.

Related problems

There are two problems connected to this one; I don't know if they deserve their own issues.

1. In addition to the reserved list, account.sh create appears to restrict to subdomains of the server. Imagine despite hosting my server at bsky.example.com, I happen to control the separate domain example.net and want to use it as a bsky handle:

   $ bash ../pdsadmin/account.sh create
   Enter an email address (e.g. [email protected]): [email protected]
   Enter a handle (e.g. alice.bsky.example.com): example.net
   ERROR: Not a supported handle domain
   Usage: ../pdsadmin/account.sh create <EMAIL> <HANDLE>
   

   Ideally, the --override should also make it possible for an administrator to register an account on a separate domain they are setting up a DID for. (But I don't know if this would be more complicated to implement for some reason.)

2. Minor, but something about the way account.sh create is implemented means that every time account.sh create is called unsuccessfully, an invite code is generated and thrown away. So having run this script 8 times trying to get it to work and then filing this bug, it turns out I've dropped 8 invite codes in my database that will never be redeemed. The script does not indicate to the user this has happened.

Logs

Here's what running with the "test" test case at the top of this issue looks like in the journalctl logs.

{
  "level": 30,
  "time": 1713911337241,
  "pid": 110769,
  "hostname": [redacted],
  "name": "pds",
  "req": {
    "id": 1793,
    "method": "POST",
    "url": "/xrpc/com.atproto.server.createInviteCode",
    "query": {},
    "params": {},
    "headers": {
      "host": "localhost:3002",
      "authorization": "Basic admin",
      "user-agent": "curl/7.68.0",
      "accept": "*/*",
      "content-type": "application/json",
      "x-forwarded-for": [redacted],
      "x-forwarded-host": "bsky.example.com",
      "x-forwarded-server": "bsky.example.com",
      "content-length": "15",
      "connection": "Keep-Alive"
    }
  },
  "res": {
    "statusCode": 200,
    "headers": {
      "x-powered-by": "Express",
      "access-control-allow-origin": "*",
      "content-type": "application/json; charset=utf-8",
      "content-length": "40",
      "etag": [redacted],
      "vary": "Accept-Encoding"
    }
  },
  "responseTime": 1,
  "msg": "request completed"
}
{
  "level": 50,
  "time": 1713911337274,
  "pid": 110769,
  "hostname": [redacted],
  "name": "HandleNotAvailable",
  "status": 400,
  "message": "Reserved handle",
  "msg": "error in xrpc method com.atproto.server.createAccount"
}
{
  "level": 30,
  "time": 1713911337275,
  "pid": 110769,
  "hostname": [redacted],
  "name": "pds",
  "req": {
    "id": 1794,
    "method": "POST",
    "url": "/xrpc/com.atproto.server.createAccount",
    "query": {},
    "params": {},
    "headers": {
      "host": "localhost:3002",
      "user-agent": "curl/7.68.0",
      "accept": "*/*",
      "content-type": "application/json",
      "x-forwarded-for": [redacted],
      "x-forwarded-host": "bsky.example.com",
      "x-forwarded-server": "bsky.example.com",
      "content-length": "161",
      "connection": "Keep-Alive"
    }
  },
  "res": {
    "statusCode": 400,
    "headers": {
      "x-powered-by": "Express",
      "access-control-allow-origin": "*",
      "content-type": "application/json; charset=utf-8",
      "content-length": "58",
      "etag": [redacted],
      "vary": "Accept-Encoding"
    }
  },
  "responseTime": 4,
  "msg": "request completed"
}

Because github is public, I have replaced all instances of my personal domain in this issue with "example.com". If you need unredacted logs I can get you some.

Currently the pdsadmin help command says this about resetting accounts passwords

password-reset <DID>
    Reset a password for an account specified by DID.
    e.g. pdsadmin account reset-password did:plc:xyz123abc456

however the account script expects reset-password instead:

Either the help text should be updated to reset-password or the account script should expect password-reset