jamesrwhite / minicron

🕰️ Monitor your cron jobs
GNU General Public License v3.0
2.34k stars 154 forks source link

Using an nginx proxy, minicron redirects back to 127.0.0.1:9292 #290

Closed shaungilroy closed 6 years ago

shaungilroy commented 7 years ago

screen shot 2017-06-27 at 3 04 26 pm

When I set up minicron to use a domain with nginx proxying to the Rackup host, every time I try to save or execute an activity, the server redirects to 127.0.0.1:9292. For example https://127.0.0.1:9292/job/1 instead of https://[:hostname]/job/1

Is there a way to configure minicron so it doesn't do this? There are a lot of settings in the toml file whose function are not entirely clear to me.

shaungilroy commented 7 years ago

It was a sinatra configuation problem and I fixed it by adding a setting line to the following file.

This was documented under the list of settings for sinatra at: http://www.sinatrarb.com/intro.html

Since I've figured this out on my own, I'm closing the issue.

jamesrwhite commented 7 years ago

I'm going to re-open this and look into it when I can as patching the installed gems code isn't really a valid fix.

jamesrwhite commented 7 years ago

Could you share your nginx/minicron.toml config (with sensitive details removed/altered if needed) so I can recreate this?

shaungilroy commented 7 years ago

Sure thing! I'll give you a steps to reproduce outline here when I get a chance this evening!

shaungilroy commented 7 years ago

Okay. After working with this for a few days, here's the setup I did that threw a curveball into the works.

On my network I have a mac mini I've named for the purposes of this example minicron.local I installed minicron there and am using that host as the hub.

  1. minicron.local is configured to run at 127.0.0.1:9292
  2. minicron.local has nginx installed on it
  3. whenever I go to minicron.local from my laptop and try to save something, I get redirected to 127.0.0.1:9292 and I get the error I posted at the beginning of the issue.

I'm attaching the minicron.local toml and nginx.conf here so you can review them and offer suggestions in case I'm misconfiguring something. I think the main reason that I'm seein errors is because I'm not running the hub from my local machine but instead a machine elsewhere on my network.

minicron.toml

# Example config file

# Global options
verbose = false
debug = false # Useful for debugging

# Client options
[client]
  [client.server]
  scheme = "http" # [http, https]
  host = "127.0.0.1"
  # username = "username" # optional for basic auth
  # password = "password" # optional for basic auth
  port = 9292
  path = "/"
  connect_timeout = 5
  inactivity_timeout = 5
  # CLI options
  [client.cli]
  mode = "line" # [line, char]
  dry_run = false

# Server options
[server]
host = "127.0.0.1"
port = 9292
path = "/"
pid_file = "/tmp/minicron.pid"
timezone = "UTC"
  [server.session]
  name = "minicron.session"
  domain = "minicron.local"
  path = "/"
  ttl = 86400
  secret = "change_me"
  [server.database]
  type = "mysql" # [mysql, postgresql, sqlite]
  # The options below are for mysql and postgresql only
  host = "127.0.0.1"
  database = "minicron_production"
  username = "[redacted]"
  password = "[redacted]"
  [server.ssh]
  connect_timeout = 10

# Alerting options
[alerts]
  [alerts.email]
  enabled = false
  # from = "from@example.com" # "Your Name <from@example.com>" syntax is also supported
  # to = "to@example.com"
    [alerts.email.smtp]
    address = "localhost" # "smtp.gmail.com" for gmail
    port = 25 # 587 for gmail
    # domain = "your.domain.name"
    # user_name = "username@email.com"
    # password = "password"
    # authentication = "plain"
    enable_starttls_auto = true

  [alerts.sms]
  enabled = false
  # from = "+442222222222"
  # to = "+443333333333"
    [alerts.sms.twilio]
    # account_sid = "YOUR_TWILIO_ACCOUNT_SID"
    # auth_token = "YOUR_TWILIO_AUTH_TOKEN"

  [alerts.pagerduty]
  enabled = false
  # service_key = "YOUR_PAGERDUTY_SERVICE_KEY"

  [alerts.aws_sns]
  enabled = false
  # secret_access_key = "YOUR_SECRET_ACCESS_KEY"
  # access_key_id = "YOUR_ACCESS_KEY_ID"
  # region = "AWS_REGION"
  # topic_arn = "YOUR_SNS_TOPIC_ARN"

  [alerts.slack]
  enabled = false
  #webhook_url = "YOUR_SLACK_WEBHOOK_URL"
  #channel = "#YOUR_SLACK_CHANNEL"

nginx.conf

# The user and group you want nginx to run as
user www-data;

# The number of processes, it's generally thought that
# this should equal how many CPU cores you have
 worker_processes 4;

events {
    # How many connections one worked can handle
    # See: http://wiki.nginx.org/EventsModule
    worker_connections 1024;
}

http {
    # Include nginx's mime types for files
    include mime.types;

    # Set the default content type
    default_type application/octet-stream;

    # Enable GZIP - optional
    gzip on;

    # Enable GZIP on the content types that minicron uses
    # text/html is always enabled when gzip is on
    gzip_types text/css text/javascript application/javascript application/json;

    # This host def is to keep the load balancer happy
    server {
        server_name _;
        root /var/www/html;
        index index.html index.htm index.nginx-debian.html;

        location / {
            try_files $uri $uri/ =404;
        }

    }

    server {
        # The port you want minicron to be available, with nginx port 80
        # is implicit but it's left here for demonstration purposes
        listen 80;

        # The host you want minicron to available at
        server_name minicron.local;

        location / {
            # Pass the real ip address of the user to minicron
            proxy_set_header X-Real-IP $remote_addr;

            # minicron defaults to running on port 9292, if you change
            # this you also need to change your minicron.toml config
            proxy_pass http://127.0.0.1:9292;
        }
    }
}

Let me know if you have any questions. I'm really impressed with your project here and am happy to help with troubleshooting as I'm able.

shaungilroy commented 7 years ago

I have largely solved this problem by making the changes I noted above. But I'm still getting redirected to 127.0.0.1 whenever I try to view an /execution/{:id}. I'm still investigating this problem.

shaungilroy commented 7 years ago

screen shot 2017-07-03 at 2 29 36 pm

Additional notes here. I've been poking at the system on and off for the past few days... I'm still having problems with the nginx reverse proxy. But the latest problem I'm encountering is unique to the index page for me: The redirect to /execution/:id is giving me a sinatra routing error (screen attached).

Now my testing seems to indicate that if I then restart nginx and then hit the execution path (/execution/131, for example), the execution path starts working. But once the execution URL begins working, /alerts starts displaying the same basic error message. This is 100% reproducible. Restarting nginx and hitting one will cause it to work, but then the other stops working. So obviously the problem is somewhere in nginx.

However, I can make both errors go away by changing the file: minicron/lib/minicron/hub/controllers/index.rb

class Minicron::Hub::App
  get '/' do
    # Get the most recent job execution
    @execution = Minicron::Hub::Execution
                           .includes(:job)
                           .order(:created_at => :desc, :started_at => :desc)
                           .first

    # Redirect the user to that execution if we found one
    if @execution
      erb :'executions/show', :layout => :'layouts/app'
    else
      erb :'index', :layout => :'layouts/app'
    end
  end
end

Note, in this version of the file I'm simply replacing the redirect with an erb directive. This is suspicious to me because now we're back to problems with the Sinatra redirect...

I cannot figure out where Minicron keeps it's application logs when installed with the install.sh script. Could you let me know how I can get the system logging for me so I have more visibility as to what's happening in the Sinatra end of things?

shaungilroy commented 7 years ago

Never mind. I see the command-line arguments will do the trick for logging/debugging.

shaungilroy commented 7 years ago

So. To bury you with information today, I've sorted out what seems to have been happening with the /executions/:id, /alerts path for me. when I run the minicron server stop it doesn't appear to be shutting down the server instance properly.

Steps to reproduce (on hub):

  1. Be sure nginx is loaded.
  2. run: 'minicron server start'
  3. hit http://mincron.local and browse pages; no errors present
  4. run: 'minicron server stop'
  5. run: 'minicron server start'
  6. hit http://mincron.local and browse pages; /execution... or /alerts paths throw sinatra exception
  7. Reboot the machine and start minicron server; once again, no errors present
  8. Repeat as necessary

In light of this, I reverted my minicron/lib/minicron/hub/controllers/index.rb file, since it was not actually the source of the problems I was experiencing.

TLDR; A reboot is required for hub to work any time I stop minicron server or else errors present while accessing the hub through nginx proxy_pass.