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.