Posts by watermelon

    Thanks for the replies everybody.


    mcktr

    I tried to set up the reverse proxy as birkch and dnsmichi had mentioned as well but was unable to successfully do so (details below). I then tried to edit the address on which Thin is listening to but I'm thinking perhaps I need to create another VirtualHost for port 8005 in my SSL configs for this to work? You and dnsmichi both use Nginx, but I don't think I should run Nginx and Apache concurrently. I think birkch's solution sums up a translation from dnsmichi's from Nginx to Apache anyways.


    birkch

    This solution technically worked, but since I have set up my Icingaweb2 to run under / instead of /icingaweb2, Dashing now runs in place of Icingaweb2 and therefore Icingaweb2 will not work. I tried to change the reverse proxy rule to serve under a different location, like /dashing, but that didn't quite work and I'm not sure if it should work like that.


    I'm not done troubleshooting yet but just wanted to update you guys on where I'm at before I take vacation.

    Hello forum,


    I recently did some apache/ssl configs which basically allowed icingaweb2 to run off / rather than /icingaweb2 and also redirect HTTP to HTTPS. More details here: Redirect for icingaweb2 (https://example/ to https://example/icingaweb2)


    I also decided to pick up Dashing again, but when I try to access it via https://, it gives a ERR_SSL_PROTOCOL_ERROR. I also get the following logs when I start Dashing in the foreground:


    I couldn't find anything new in the ssl_error_log but I did see these logs in ssl_access_log when I refresh the Dashing page:


    Code
    1. x.x.x.x - - [19/Sep/2017:14:38:09 -1000] "GET /js/icinga.min.js HTTP/1.1" 304 -
    2. x.x.x.x - - [19/Sep/2017:14:38:10 -1000] "GET /js/icinga.min.js HTTP/1.1" 304 -
    3. x.x.x.x - - [19/Sep/2017:14:38:09 -1000] "GET /css/icinga.min.css HTTP/1.1" 200 205325
    4. x.x.x.x - - [19/Sep/2017:14:38:10 -1000] "GET /css/icinga.min.css HTTP/1.1" 304 -
    5. x.x.x.x - - [19/Sep/2017:14:38:10 -1000] "GET /layout/menu HTTP/1.1" 200 4848
    6. x.x.x.x - - [19/Sep/2017:14:38:10 -1000] "GET /layout/menu HTTP/1.1" 200 4848

    My API connection configs must be correct because I'm still getting data into the Dashing interface via HTTP. I had to specify "pki_path" as well as "node_name" and copy my SSL certs into the dashing directory as discussed in the docs under the Dashing Configuration section.


    Here's some more information:

    Code
    1. # gem list --local dashing
    2. dashing (1.3.7)
    3. # ruby -v
    4. ruby 2.0.0p648 (2015-12-16) [x86_64-linux]
    5. # cat RELEASE.md
    6. VERSION=1.3.0


    Anyone have any pointers? Basically I'm just trying to get Dashing to work with HTTPS. Would I have to make another vhost? I tried to do it myself following the icingaweb2 apache configs but I doubt it's correct:



    Thanks for any help!

    hi Ingvar ,


    I use a plugin called check_snmp_int.pl (check it out here http://nagios.manubulon.com/snmp_int.html).


    Basically, all you have to provide is hostname, authentication method (v2 or v3 credentials), interface name, and warning/critical thresholds and you'll be able to monitor interfaces by SNMP. I can provide you some configs to get you started if you like, but it's relatively straightforward.


    Here's an example of what it looks like!




    As you can see, I've configured my checks to show incoming/outcoming traffic as well. You can also monitor ports that are meant to be down but will alert you as soon as they come up, which I have in place also.

    so I figured it out -- I had to add a couple extra lines to your config right above the 'director' definition to redirect from http to https:


    Code
    1. RewriteCond %{HTTPS} !on
    2. RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}


    I also had to edit the ssl config to include the new vhost config you gave me since one of the paths for DocumentRoot was configured incorrectly (like you said). I'm also guessing I had to do this because I needed a VirtualHost definition for port 443 in addition to port 80 from your vhost config to work with https.


    It all now works! All I have to do is enter in my servername into the address bar and automatically redirects me to https://servername/dashboard (if I'm logged in), from which icingaweb2 now operates.


    Thanks for all the help!


    P.S.

    If anybody else runs into this problem, please reply to the thread so I can share configs if necessary.

    Hi dnsmichi ,


    I implemented your configuration and modified it to fit my environment (changed servername), but it's not quite working as expected. If I try to access "icinga2.server.name", it redirects to "https://icinga2.server.name" but it's still a blank page like before.


    If I explicitly write "http://icinga2.server.name", it will redirect to "http://icinga2.server.name/icingaweb2" but it won't be https.


    I also deleted the default icingaweb2.conf in /etc/httpd/conf.d/ because I'm guessing the vhost definitions would conflict with each other.


    Additionally, I tried just using the first puppet template you pasted as my vhost definition but that didn't work (didn't expect it to)


    Not sure if I'm missing something obvious, and I apologize if I am.

    Hi dnsmichi and Kevin.Honka ,


    I tried dnsmichi's solution first. I removed my config from httpd.conf and into /conf.d/vhosts.conf but commented it out to try letting "/ serve Icinga Web 2".


    I wasn't quite sure how to go about this, but I assume that the configs for this are in /etc/httpd/conf.d/icingaweb2.conf. I found the excerpt which seems to handle the usage of /icingaweb2/. I replaced the default RewriteBase line:

    Code
    1. <IfModule mod_rewrite.c>
    2. RewriteEngine on
    3. #RewriteBase /icingaweb2/
    4. RewriteBase /
    5. RewriteCond %{REQUEST_FILENAME} -s [OR]
    6. RewriteCond %{REQUEST_FILENAME} -l [OR]
    7. RewriteCond %{REQUEST_FILENAME} -d
    8. RewriteRule ^.*$ - [NC,L]
    9. RewriteRule ^.*$ index.php [NC,L]
    10. </IfModule>

    But when I try to access https://icinga2.server.name/, all I get is a blank page (expected) and when I try to manually go to https://icinga2.server.name/icingaweb2/, I get this error:

    Not Found

    The requested URL /index.php was not found on this server.

    I'm guessing this is because it's still looking for /index.php at / but it's actually at /icingaweb2/index.php still?


    I'm also guessing this is what Kevin addresses in this line of his config,


    location ~ ^/icingaweb2/index\.php(.*)$


    However, I wasn't quite sure how to convert this syntax from nginx into apache and also wasn't completely certain of what it does.


    Sorry, I don't know much about apache config.

    Hi all,


    I apologize for this question not being specifically related to icingaweb2, but it is related to http/https and redirects that perhaps some other people want to implement.


    I noticed that when you try to access the icinga web interface through 'http://icinga2.server.name/', all you see is a white page. You need to access it through 'http://icinga2.server.name/icingaweb2/' from which you will get redirected to 'http://icinga2.server.name/icingaweb2/dashboard'.


    I was able to implement the redirect stated above, but I can't seem to get it working with https (if I were to access the interface from 'https://icinga2.server.name/'). Here are my current configs:

    Code: /etc/httpd/conf/httpd.conf
    1. <VirtualHost *:80>
    2. Servername https://icinga2.server.name
    3. RedirectMatch permanent ^ https://icinga2.server.name/icingaweb2/dashboard
    4. # Redirect https://icinga2.server.name https://icinga2.server.name/icingaweb2/dashboard
    5. </VirtualHost>


    The line commented out doesn't seem to work (or do anything) but I included it so you could follow my thought process.


    Has anybody else implemented this type of thing? Is there something obvious I'm missing? Desperately need a second pair of eyes to look over this.


    Thanks!

    Quote

    But icinga2 is a pure application server

    Hmm, so even if icinga2 is a pure application server, it can have a local database until you decide to have an HA cluster setup, at which point you will need to have an external sql server? Meaning that it wouldn't make sense to have the sql server cluster located on one of the masters for both masters to write to?

    I'm incredibly grateful for such an offer but I am just not comfortable with hosting a remote session like that (I'm sure my company wouldn't be either). However, I can be given a list of commands to run (which would what would be in the remote session anyways) from which an expert like Mikesch could decipher. I don't see how this would be any different from a remote session, other than it being real-time vs delayed responses.

    Hey, if anyone is running into this problem, I have a solution!


    You must import all dependencies of the plugin you are running into the jail. To find the dependencies, run the following command:


    strace -xvtto /tmp/strace.out /usr/lib64/nagios/plugins/check_disk -w 1 -c 2


    Obviously, replace the plugin I'm using with the one you're using.


    -x Prints all non-ASCII strings in hexadecimal string format.
    -v Prints unabbreviated versions of environment, stat, termios, etc. calls.
    -tt If given twice, the time printed will include the microseconds.
    -o filename Write the trace output to the file filename rather than to stderr. Use filename.pid if -ff is used. If the argument begins with `|’ or with `!’ then the rest of the argument is treated as a command and all output is piped to it.


    All the information above is taken from this blog: https://www.pythian.com/blog/u…lication-errors-in-linux/



    After you run that command, view the outputted file in /tmp/strace.out. In there, it will show all the dependencies for the command. Import all the necessary ones using this command from Jailkit:


     jk_cp -v -f -k -j /home/jail DEPENDENCY_DIRECTORY


    -v verbose, show what's being copied

    -f force, overwrite existing files

    -k hardlink, use hardlinks if possible

    -j jail, the jail to copy to


    From there, you should be able to execute the plugin from the jail as the jailed user without hitches. In my case, I had to create some extra directories for the plugin to write to indicated by some error messages when I tried running it.

    Hi,


    I hate to hijack this thread (if it can be considered that), but I feel that my problem may be pertinent to @tdmike's implementation with his HA setup.


    Regarding the SQL-Server redundancy that sru mentioned, how exactly do you set that up? I'd like to point out this excerpt from the docs:



    For the line 1, since the DB IDO feature by default only runs on one node, does that mean it must be enabled for the secondary master? If so, does it starting working by default? In my instance, I can't seem to get it working with my primary master and secondary master both having the ido_mysql feature enabled with enable_ha = true. I get the error saying "Backend Icinga2 is not running" and the idodb doesn't seem to be connected.


    For line 3, it mentioned that all endpoint will have the DB IDO feature enabled and "connect to the configured database". How would that be set up?

    Sorry for the late response.


    I still have not solved the problem. Last time, that command Mikesch gave me to run seemed to work:


    systemctl stop icinga2 && rm -f /var/log/icinga2/icinga2.log && systemctl start icinga2 && sleep 10 && fgrep -i ido /var/log/icinga2/icinga2.log


    However, it didn't seem to last. A couple weeks later I seem to be having the same problem as I had before. This time, I ran @dnsmichi's programstatus query from here and have found that while the web interface shows that the backend is not running, the query gives no output but during the few minutes that it does run right after I restart the service, it does give an output. What exactly do I do with this information?


    As a last resort, I reinstalled the icinga2-ido-mysql and icingaweb2 packages and also applied the latest schema upgrade, but that didn't seem to help either.

    As the subject describes, my director configurations will not deploy. When I try to, I receive the following error in red text:


    CURL ERROR: Could not resolve host: MASTER1NAME; Name or service not known (RestApiClient.php:177)


    I couldn't find much on Google about this. I'm also not sure if this is related to my HA cluster setup, which I'm having trouble with at the moment. The error described above seemed to only appear recently, when I configured the HA setup.


    Anyone have any clues? Thanks in advance.