-
Notifications
You must be signed in to change notification settings - Fork 991
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fixes #29507 - Add puma-status for reporting #7578
Conversation
Issues: #29507 |
this PR requires packaging of https://rubygems.org/gems/puma-status/versions/1.0 in https://github.com/theforeman/foreman-packaging |
I squashed all the commits, test and the output is: # systemctl restart foreman
# journalctl -u foreman -f
Apr 09 18:57:39 centos7-katello-nightly.apex.example.com systemd[1]: Started Foreman.
Apr 09 18:57:42 centos7-katello-nightly.apex.example.com foreman[7802]: /usr/share/foreman/lib/foreman.rb:8: warning: already initialized constant Foreman::UUID_REGEXP
Apr 09 18:57:42 centos7-katello-nightly.apex.example.com foreman[7802]: /usr/share/foreman/lib/foreman.rb:8: warning: previous definition of UUID_REGEXP was here
Apr 09 18:57:43 centos7-katello-nightly.apex.example.com foreman[7802]: => Booting Puma
Apr 09 18:57:43 centos7-katello-nightly.apex.example.com foreman[7802]: => Rails 5.2.1 application starting in production
Apr 09 18:57:43 centos7-katello-nightly.apex.example.com foreman[7802]: => Run `rails server -h` for more startup options
Apr 09 18:57:55 centos7-katello-nightly.apex.example.com foreman[7802]: [7802] Puma starting in cluster mode...
Apr 09 18:57:55 centos7-katello-nightly.apex.example.com foreman[7802]: [7802] * Version 4.3.3 (ruby 2.5.5-p157), codename: Mysterious Traveller
Apr 09 18:57:55 centos7-katello-nightly.apex.example.com foreman[7802]: [7802] * Min threads: 0, max threads: 16
Apr 09 18:57:55 centos7-katello-nightly.apex.example.com foreman[7802]: [7802] * Environment: production
Apr 09 18:57:55 centos7-katello-nightly.apex.example.com foreman[7802]: [7802] * Process workers: 2
Apr 09 18:57:55 centos7-katello-nightly.apex.example.com foreman[7802]: [7802] * Phased restart available
Apr 09 18:57:55 centos7-katello-nightly.apex.example.com foreman[7802]: [7802] * Activated tcp://127.0.0.1:3000
Apr 09 18:57:55 centos7-katello-nightly.apex.example.com foreman[7802]: [7802] Use Ctrl-C to stop
Apr 09 18:57:55 centos7-katello-nightly.apex.example.com foreman[7802]: [7802] * Starting control server on unix:///var/run/foreman/foreman-pumactl.sock
Apr 09 18:57:55 centos7-katello-nightly.apex.example.com foreman[7802]: [7802] - Worker 0 (pid: 7842) booted, phase: 0
Apr 09 18:57:55 centos7-katello-nightly.apex.example.com foreman[7802]: [7802] - Worker 1 (pid: 7846) booted, phase: 0
# ll /var/run/foreman/pids
total 12
-rw-r--r--. 1 foreman foreman 5 Apr 9 18:57 puma.pid
-rw-r--r--. 1 foreman foreman 124 Apr 9 18:57 puma.state
-rw-r--r--. 1 foreman foreman 4 Apr 9 18:57 server.pid
# cat /var/run/foreman/pids/puma.state
---
pid: 7802
control_url: unix:///var/run/foreman/foreman-pumactl.sock
control_auth_token: f498f3f689f023ee6afe6e82699f36c
# cat /var/run/foreman/pids/puma.pid
7802
# /bin/bash /usr/share/foreman/script/foreman-puma-status
7802 (/var/run/foreman/pids/puma.state) Uptime: 2m17s | Phase: 0 | Load: 0[░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░]32
└ 7842 CPU: 0.0% Mem: 294 MB Uptime: 2m17s | Load: 0[░░░░░░░░░░░░░░░░]16
└ 7846 CPU: 0.0% Mem: 294 MB Uptime: 2m17s | Load: 0[░░░░░░░░░░░░░░░░]16 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The use of /var/run
is generally deprecated since systemd introduced /run
. It is also a symlink on all platforms we support now. In packaging we ensure this directory exists by creating /usr/lib/tmpfiles.d/foreman.conf
.
On a related, note, we still symlink /usr/share/foreman/tmp
to /var/run/foreman
instead of /run/foreman
. A brief look tells me we should be using RuntimeDirectory=foreman
in foreman.service
but then we also need to take a look at the cache
directory. The more I looked into this, the more things I saw to improve. https://www.freedesktop.org/software/systemd/man/systemd.exec.html#RuntimeDirectory= has a nice list but Rails doesn't have a variable to change the tmp
directory and just uses Rails.root.join('tmp')
all over the place. That's why packaging symlinks it.
I also see that /run/foreman/sockets
exists, but is empty. It appears this is a Rails convention and we should be making use of that.
You're now only configuring this for production, but shouldn't this be a general config? development also uses puma and it'd be nice to test the same tools there.
config/puma/production.rb
Outdated
pid_dir = '/var/run/foreman/pids' | ||
|
||
# Store the pid of the server. | ||
pidfile "#{pid_dir}/puma.pid" | ||
|
||
# Store server info state. | ||
state_path "#{pid_dir}/puma.state" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
pid_dir = '/var/run/foreman/pids' | |
# Store the pid of the server. | |
pidfile "#{pid_dir}/puma.pid" | |
# Store server info state. | |
state_path "#{pid_dir}/puma.state" | |
run_dir = Rails.root.join('tmp') | |
# Store the pid of the server. | |
pidfile File.join(run_dir, 'pids', 'puma.pid') | |
# Store server info state. | |
state_path File.join(run_dir, 'puma.state') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks @ekohl , to make it even simpler, should we perhaps just use
run_dir = "/run/foreman"
script/foreman-puma-status
Outdated
@@ -0,0 +1,2 @@ | |||
#!/bin/bash | |||
puma-status /var/run/foreman/pids/puma.state |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
puma-status /var/run/foreman/pids/puma.state | |
puma-status /run/foreman/puma.state |
config/puma/production.rb
Outdated
pid_dir = '/var/run/foreman/pids' | ||
|
||
# Store the pid of the server. | ||
pidfile "#{pid_dir}/puma.pid" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reading further about this, the default pid is tmp/pids/server.pid
and I don't see the need to change this. I also think that rails server
has a --pid
option to change this and there's no real reason to hardcode it. In systemd we don't even care about pids at all since it's all managed for us. Am I missing something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you are right, we are concerned about the state_path
option only and there is no need to change pidfile
option. I changed it to make sure the pid
and state
files live together, but it doesn't matter. I will remove this entry.
I can submit a change for dev environment, which repository should this change be submitted to? |
Are there packaging PRs (both deb and RPM) to make sure |
I see this PR theforeman/foreman-packaging#5031 manipulates |
Packaging change for RPM: |
Any further comments or concerns with this? With packaging PRs open, I believe this is GTG. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving if my assumption is correct.
@@ -17,3 +22,6 @@ | |||
dynflow = ::Rails.application.dynflow | |||
dynflow.initialize! unless dynflow.config.lazy_initialization | |||
end | |||
|
|||
# === Puma control rack application === | |||
activate_control_app "unix://#{run_dir}/sockets/pumactl.sock" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't checked the permissions on this, but I'm assuming it's foreman:foreman
and 0644
which should prevent from everyone writing to it. Correct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is how it looks now:
# ll -d /run/foreman/ /run/foreman/sockets
drwxr-xr-x. 5 foreman foreman 200 Apr 22 14:30 /run/foreman/
drwxr-xr-x. 2 foreman foreman 60 Apr 22 14:23 /run/foreman/sockets
# ll /run/foreman/sockets
total 0
srwxrwxrwx. 1 foreman foreman 0 Apr 22 14:23 pumactl.sock
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does that mean that any user can connect to the socket and restart the server?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are these determined by packaging?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, looks like a postgres
user is able to restart the puma server if right control_url
and control_auth_token
is known. Any suggestions on how to lock this down further?
# ll /var/run/foreman/puma.state
-rw-r--r--. 1 foreman foreman 120 Apr 22 15:23 /var/run/foreman/puma.state
# cat /var/run/foreman/puma.state
---
pid: 1672
control_url: unix:///run/foreman/sockets/pumactl.sock
control_auth_token: 6c445af0312fff70fe0f190a65644cf
# sudo -u postgres scl enable tfm 'pumactl --control-url 'unix:///var/run/foreman/sockets/pumactl.sock' --control-token 6c445af0312fff70fe0f190a65644cf restart'
Command restart sent success
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What are the permissions on viewing the control token?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
see the first line of my post above. the control token is present in puma.state file which has permissions 644
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All I can think is having something to adjust the permissions after creation but really the answer is to get a change into Puma to allow configuring the state file permissions.
Is it possible to put the state file in a directory that is not globally readable?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All I can think is having something to adjust the permissions after creation but really the answer is to get a change into Puma to allow configuring the state file permissions.
I am working to get a fix to the puma project.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Submitted patch to puma project puma/puma#2238 to address the state file security issue.
Blocked on the linked PR (puma/puma#2238). There's good progress on it. |
Note that puma/puma#2238 is merged now. So I added a new commit to this PR to add state_permission of |
Note that merged doesn't mean available. You'll need to wait for a gem to include it and require at least puma x.y.z. |
The related Puma fix is merged and released in Puma. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should now require the right puma version but other than that 👍
closing in favor of gh-7735 |
Note the foreman packaging change is still pending to include
puma-status
gem as rpm