[HOWTO] Self-hosting feature thought: integration of LibreX into the /e/Cloud setup

eOSWiki HOWTOs
, ,
6

Huzzah, Success!!

The distilled set of steps for the next person (and, as a recommendation to the next person, go back and read what Sylvain wrote, it’s worth the read):

  1. Create an A record subdomain in your registrar; point it to the same WAN IP as the rest of the A records to your server.
  2. ssh into your server, and get the cert in place:
    1. nano /mnt/repo-base/config/letsencrypt/autorenew/ssl-domains.dat
    2. add your domain to the bottom of the list.
    3. docker stop nginx
    4. cd /mnt/repo-base-scripts && ./ssl-renew.sh
    5. docker start nginx
  3. Add LibreY to the docker compose file:
    1. nano /mnt/repo-base/docker-compose.yml
    2. paste the docker-compose file from below; there are no passwords or example configs so you can use it as-is unless you want to make changes to the environment variables.
    3. Create the folder for the php files: mkdir /mnt/repo-base/volumes/librey && mkdir /mnt/repo-base/volumes/librey/php_logs
    4. set permissions for the php_logs folder. I was super lazy and made it 777, but I’m assuming that more restrictive permissions will work.
  4. Add the nginx config:
    1. nano /mnt/repo-base/config/nginx/sites-enabled/search.voyager529.com.conf
    2. paste the nginx config file from below.
    3. do a find/replace for REPLACE_THIS and replace it with the subdomain you made in step 1 (you can also use the sed command for this; again, I’m lazy).
  5. Implement the config:
    1. docker-compose down
    2. docker-compose up -d
docker-compose file 
    image: ghcr.io/ahwxorg/librey:latest
    container_name: librey
    environment:
      - CONFIG_GOOGLE_DOMAIN=com
      - CONFIG_LANGUAGE=en
      - CONFIG_NUMBER_OF_RESULTS=10
      - CONFIG_INVIDIOUS_INSTANCE=https://yt.ahwx.org
      - CONFIG_DISABLE_BITTORRENT_SEARCH=false
      - CONFIG_HIDDEN_SERVICE_SEARCH=false
      - CONFIG_INSTANCE_FALLBACK=true
      - CONFIG_RATE_LIMIT_COOLDOWN=25
      - CONFIG_CACHE_TIME=20
      - CONFIG_DISABLE_API=false
      - CONFIG_TEXT_SEARCH_ENGINE=auto
      - CURLOPT_PROXY_ENABLED=false
      - CURLOPT_PROXY=192.0.2.53:8388
      - CURLOPT_PROXYTYPE=CURLPROXY_HTTP
      - CURLOPT_USERAGENT=Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:116.0) Gecko/20100101 Firefox/116.0
      - CURLOPT_FOLLOWLOCATION=true
    volumes:
      # - ./nginx_logs:/var/log/nginx # Disabled by default. These are the NGINX request logs.
      - ./php_logs:/mnt/repo-base/volumes/librey/php_logs # Enabled by default. These are the PHP error logs.
    restart: unless-stopped
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
nginx config file

server {
listen 8000;
server_name REPLACE_THIS;
location / {
return 301 https://$host$request_uri;
}
}

server {
listen 4430 ssl http2;
server_name REPLACE_THIS;

ssl_certificate /certs/live/REPLACE_THIS/fullchain.pem;
ssl_certificate_key /certs/live/REPLACE_THIS/privkey.pem;

include /etc/nginx/params/ssl_params;
include /etc/nginx/params/headers_params;

location / {
proxy_pass http://librey:8080;
include /etc/nginx/params/proxy_params;
}
}

And…that’s it!!

Bonus: I only needed to do a single search for the /e/OS browser to let me set it as a default.

As always, thanks so much to @smu44 for all of his guidance.

One more thing, more of a ‘public-private message’ to Sylvain: my particular environment uses a set of VMs on a single subnet. My KitchenOwl instance is on a separate VM from my /e/Cloud instance, but they’re on the same LAN. I’ve done similar work in AWS (old habits die hard, I guess), hence the original thought of adding LibreY to the second VM.

While certainly debatable, there are a few reasons for this topology. First, I’m not big on having several applications share a single database. Since database instances are very small, they’re easy to separate out, largely so that a failure of one database leaves other applications functioning. The second reason for this is to limit resource usage; I’m happy to give a huge amount of disk space to my /e/Cloud instance so it can keep a complete backup of my photos, but I can give my other containers, like KitchenOwl, a very small amount of storage space and put it on a smaller SSD volume instead of the 4TB HDD volume that /e/Cloud enjoys. I understand this makes less sense on a VPS, but, well, I don’t run a VPS :stuck_out_tongue: .

Thank you again!

1 Like