Installation guide without Docker?

[riahc3]

• I've searched the project's issues.
• I've searched the project's discussions.

❓ Question

How can I install PasswordPush in a non Docker environment ?

📎 Additional context

I want to use your typical manual Apache/NGINX, MariaDB, PHP, etc. setup and then install PasswordPusher there. I dont want to use containers or any sort of similar "prepackaged" setup.

Is there any guide? The closest thing Ive seen is the from source but it seems like it just like using Ruby as a proxy/web server

[github-actions]

Hello @riahc3, thanks for contributing to the Password Pusher community! We will respond as soon as possible.

[pglombardo]

Hi @riahc3 - this is a rare request so unfortunately I don't have end-to-end documentation written up but I can outline the major steps:

• When you have the source code, you can launch the application by running ./bin/pwpush server.
• This launches the application that listens on 0.0.0.0:5100 in plain HTTP
• If you want to configure a persistent backend, read about the DATABASE_URL environment variable
• From there, you can configure an nginx instance with an SSL certificate & backend server of 127.0.0.1:5100
• The nginx would be your SSL termination point

Password Pusher is built using a framework called Ruby on Rails. If you are deploying to some cloud, there are many services that will detect and automatically deploy the application for you such as Heroku, Hatchbox and a bunch of others.

I've marked this issue as a feature request and will put together a guide eventually.

Does the above help out any? Let me know. I can expand on any area you want to know about.

[riahc3]

Thank for your answer.

Unfortunately, this doesnt give me much path.

Does downloading the source code include the binary (pwpush) or is complying it required?

Making it listen on a port that cant be changed is kind of scary; Changing default ports, even if it can be picked up by a port scanner, would be preferred.

Although setting the database with said variable is pretty clear, what isnt clear is what database needs to be created, premissions, etc.

From what I understand, even though NGINX would be the SSL termination point, it would be acting as a reverse proxy as well, correct?

Security wise, even though the project has been here for decades, deploying to a public cloud, is not ideal: At the end of the day, these are passwords, and keeping them on a local machine would be prefered.

I think more then a guide, maybe a package to install this thru yum, apt-get, etc. would be prefered. Makes things a lot easier to deploy.

Thanks

[pglombardo]

Hi @riahc3 -

Making it listen on a port that cant be changed is kind of scary; Changing default ports, even if it can be picked up by a port scanner, would be preferred.

The listening ip:port can be changed with -p.

Although setting the database with said variable is pretty clear, what isnt clear is what database needs to be created, premissions, etc.

Fair point.

From what I understand, even though NGINX would be the SSL termination point, it would be acting as a reverse proxy as well, correct?

That's correct.

Security wise, even though the project has been here for decades, deploying to a public cloud, is not ideal: At the end of the day, these are passwords, and keeping them on a local machine would be prefered.

The tool isn't a password manager. It's used to securely communicate information to other people. It would make sense on a local machine only if that machine was accessible by others that you are transmitting sensitive information to.

I think more then a guide, maybe a package to install this thru yum, apt-get, etc. would be prefered. Makes things a lot easier to deploy.

I agree that would be nice but unfortunately I don't often get these requests and also being the sole maintainer with a day job, I have to be selective on what to focus my limited time on.

I appreciate the feedback and will give it some thought. Unfortunately, for right now, building out and supporting a fully manual installation method isn't realistic given the limited resources.

I hope this helps and maybe you will reconsider using Docker containers. They really are a simpler and more secure deployment method.

[riahc3]

Hi @riahc3 -

Making it listen on a port that cant be changed is kind of scary; Changing default ports, even if it can be picked up by a port scanner, would be preferred.

The listening ip:port can be changed with -p.

OK, understood

Although setting the database with said variable is pretty clear, what isnt clear is what database needs to be created, premissions, etc.

Fair point.

Yeah, for example: Making a MariaDB HA cluster would complicate things as we dont know the name, the permissions, etc.

From what I understand, even though NGINX would be the SSL termination point, it would be acting as a reverse proxy as well, correct?

That's correct.

Great.

Security wise, even though the project has been here for decades, deploying to a public cloud, is not ideal: At the end of the day, these are passwords, and keeping them on a local machine would be prefered.

The tool isn't a password manager. It's used to securely communicate information to other people. It would make sense on a local machine only if that machine was accessible by others that you are transmitting sensitive information to.

Correct, it isnt a password manager....HOWEVER....It does store passwords in unknown and uncontrolled locations, which, we have to trust the password that they get destroyed when their time/view limit is reached.

I think more then a guide, maybe a package to install this thru yum, apt-get, etc. would be prefered. Makes things a lot easier to deploy.

I agree that would be nice but unfortunately I don't often get these requests and also being the sole maintainer with a day job, I have to be selective on what to focus my limited time on.

I understand. Im surprised this request isnt more common as, even though the project is great, a standalone version would be perfect.

I appreciate the feedback and will give it some thought. Unfortunately, for right now, building out and supporting a fully manual installation method isn't realistic given the limited resources.

Perfectly understood.

I hope this helps and maybe you will reconsider using Docker containers. They really are a simpler and more secure deployment method.

Im sure many people will disagree but the entire Pet vs Cattle discussion: Im on the Pet side: Sysadmins should administer their infrastructure no matter how simple or complex they are.

Since this is currently the only option, I guess we will keep just using the site.

Thank you nonetheless for all your answers.

[riahc3]

My mistake, we will use your universal container suggestion :)

Or will try as Im having some issue seeing how to do a fresh installation from the start.

[pglombardo]

Excellent - here's a cheat sheet:

• Configuration Docs
• How to specify a database
• Sample Docker Compose Files

but tldr;

docker run -d -p "5100:5100" -e "DATABASE_URL=postgresql://user:passwd@postgres:5432/my_db" pglombardo/pwpush:latest

[riahc3]

My idea is to use a settings.yml to set all the variables needed.

Im gonna go ahead and give it a try as, even though Im not a docker expert , it SEEMS pretty easy

[riahc3]

I dont see any way to setup SSL with our certificate though

[riahc3]

Another issue I am having is that I have the MariaDB setup on my Debian host and when I start the Docker container, It cant find it on "localhost" (I believe the Docker container thinks localhost is the container itself so...)

Hosthost names cant be solved either as it has no access to local DNS servers

[pglombardo]

When using docker-compose - there is internal networking and DNS resolution between the containers. Things are not exposed to localhost by default. e.g. Password Pusher and a database, the only port need to be exposed to localhost is 5100 to access the application.

Even still, you can configure which exposed ports. From Groq:

You can configure which ports are exposed to localhost in Docker Compose by using the ports directive in your docker-compose.yml file.

Here is an example:

version: '3'
services:
  web:
    build: .
    ports:
      - "8080:80"

In this example, the web service will expose port 80 from the container to port 8080 on the host machine.

You can also specify multiple ports by separating them with commas:

version: '3'
services:
  web:
    build: .
    ports:
      - "8080:80"
      - "8081:81"

This will expose ports 80 and 81 from the container to ports 8080 and 8081 on the host machine, respectively.

You can also specify a range of ports by using the ports directive with a range:

version: '3'
services:
  web:
    build: .
    ports:
      - "8080-8082:80-81"

This will expose ports 80 and 81 from the container to ports 8080 and 8081 on the host machine, respectively.

You can also use the expose directive to expose a port to the host machine, but not necessarily to localhost:

version: '3'
services:
  web:
    build: .
    expose:
      - 8080

This will expose port 8080 from the container to the host machine, but not necessarily to localhost.

Note that the ports directive is used to map a container port to a host port, while the expose directive is used to expose a port to the host machine, but not necessarily to localhost.

[pglombardo]

I dont see any way to setup SSL with our certificate though

I find that asking ChatGPT/Groq is the fastest way to get answers. Hopefully this helps:

==================================

To add your custom SSL certificate to an Nginx container in a Docker Compose setup, you can follow these steps:

1. Create a new directory in the root of your project to store your SSL certificate files. For example, you can create a directory named certs.
2. Copy your SSL certificate files (private key, certificate, and any intermediate certificates) into the certs directory.
3. Update your docker-compose.yml file to mount the certs directory as a volume inside the Nginx container. For example:

version: '3'
services:
  nginx:
    image: nginx:alpine
    volumes:
      - ./certs:/etc/nginx/certs:ro
    ports:
      - "80:80"

In this example, the certs directory in the current directory is mounted as a read-only volume at /etc/nginx/certs inside the Nginx container.

4. Update your Nginx configuration file (default.conf or nginx.conf) to use your custom SSL certificate. For example:

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate /etc/nginx/certs/example.com.crt;
    ssl_certificate_key /etc/nginx/certs/example.com.key;

    # ... other configuration ...
}

In this example, Nginx will use the SSL certificate file example.com.crt and the private key file example.com.key from the certs directory.

5. Restart your Nginx container by running the command docker-compose up -d to apply the changes.

That's it! Your custom SSL certificate should now be used by Nginx in your Docker Compose setup.

[riahc3]

The issue is I dont know exactly what to ask ChatGPT 😂

I believe Docker and Docker Compose are different methods, right???

Im just using the plain Docker method. I have another problem with Rate Limit (I made another issue, sorry) but while I am on it, I noticed that SSL was not working at all; What I mean is that it wasnt going to HTTPS, just HTTP.

[pglombardo]

No problem - Docker is the base technology. Docker Compose is a tool to stitch 2 or more containers together with internal networking and DNS and treat them as a single unit.

When you run the pwpush container, it serves in HTTP. In the examples I linked above, there is an nginx container which can be the SSL termination point: Browser --> SSL --> nginx --> HTTP --> pwpush.

My crappy drawing...

[pglombardo]

It takes a bit to work through all these details but the good thing is that none of this is specific to Password Pusher. The knowledge is valid for all Docker based applications (and it worth learning IMO). Post any other issues you hit, I'll do my best to help out.

[riahc3]

No problem - Docker is the base technology. Docker Compose is a tool to stitch 2 or more containers together with internal networking and DNS and treat them as a single unit.

When you run the pwpush container, it serves in HTTP. In the examples I linked above, there is an nginx container which can be the SSL termination point: Browser --> SSL --> nginx --> HTTP --> pwpush.

My crappy drawing...

Yeah, I sadly already saw this these few minutes I was searching....Im gonna put a Netscaler in front of it so that part is figured out.

I am having that weird rate limit issue (thru HTTP) that I dont understand why