I'm getting this error message when logback is trying to create file to log:
-ERROR in ch.qos.logback.core.rolling.RollingFileAppender[file-appender] -
Failed to create parent directories for [/var/log/living/commty/logFile.log]
-ERROR in ch.qos.logback.core.rolling.RollingFileAppender[file-appender] -
openFile(/var/log/living/commty/logFile.log,true) call failed.
java.io.FileNotFoundException: /var/log/living/commty/logFile.log (Permission denied)
Nevertheless:
ls /var/log/living/commty/ -lha
total 8.0K
drw-r----- 2 wildfly wildfly 4.0K May 23 09:29 . <<<<<<<<<<<<
drw-r----- 6 wildfly wildfly 4.0K May 23 09:29 ..
As you can see /var/log/living/commty is wildfly:wildfly owned and rw-r----- (read-write access).
Any ideas?
Related
I have Artifactory 6.20.1 running in a Docker container. I'm trying to install the artifactCleanup plugin (https://github.com/jfrog/artifactory-user-plugins/tree/master/cleanup/artifactCleanup)
I have put the artifactCleanup.groovy file in the corresponding folder:
$ ls -all /opt/jfrog/artifactory/var/etc/artifactory/plugins/
total 36
drwxr-xr-x 2 artifact artifact 4096 Feb 24 10:28 .
drwxr-xr-x 3 artifact artifact 4096 Feb 23 15:24 ..
-rwxr-xr-x 1 artifact artifact 5829 Feb 23 15:25 README.md
-rwxr-xr-x 1 artifact artifact 14043 Feb 23 15:26 artifactCleanup.groovy
-rwxr-xr-x 1 artifact artifact 325 Feb 24 10:28 artifactCleanup.json
However if I'm trying to see my loaded plugins I get an empty response
curl -X GET -u "admin:password" http://localhost:8081/artifactory/api/plugins
{}
The Server has been restarted before running that request. All commands have been running inside the Docker container. I have been looking at the documentation (https://www.jfrog.com/confluence/display/JFROG/User+Plugins) on how to install plugins. My User account which was used for the rest calls is an admin account.
Now I am out of clues, why that plugin is not loading?
You can use the below reload plugins using the Reload Plugins REST API endpoint.
https://www.jfrog.com/confluence/display/JFROG/Artifactory+REST+API#ArtifactoryRESTAPI-ReloadPlugins
Please comment here if you are running into any issues.
Turns out I created a wrong directory. Correct directory is
/var/opt/jfrog/artifactory/etc/plugins
which already existed.
I have a Synology Diskstation DS216se running DSM 6.2.3-25426. I've installed MariaDB 10, Web Station, PHP 7.2, and myPhpAdmin, but when I open it at http://diskstation/phpMyAdmin/ I get this error message
"Sorry, the page you are looking for is not found."
I'm using an nginx server in Web Station, and the error log at /var/log/nginx/error.log contains multiple entries like the following
*621 open() "/var/services/web/phpMyAdmin/js/vendor/jquery/jquery.debounce-1.0.5.js" failed (13: Permission denied)
The file, and all other files with permission denied entries in the logs, exist in the /var/services/web/phpMyAdmin/ directory - what permissions need to be granted to the directory for this to succeed?
I hit this as well. I managed to recover, but it effectively amounts to hard clearing any evidence of prior installs of Web Station, PHP 7.2, phpMyAdmin, and any other web related services. Then manually ripping out some bad directories with broken symlinks/permissions.
My hypothesis is that I tried to install adminer prior to this and - having not done any set up for Web Station et. al. - it put the filesystem in a bad state.
I am not willing to try installing adminer again to test this hypothesis.
What I did to fix this:
Backup what you need (e.g., any personal web site).
SSH into your diskstation. Please be aware of what you are doing and keep in mind the big picture. Don't go deleting random things.
Uninstall Web Station, PHP 7.2, Apache, phpMyAdmin, etc. Anything that Web Station would ultimately be inclined to read and serve up.
Verify that /var/services/web doesn't contain anything you care about, and delete it (sudo rm -rf /var/services/web).
Verify that /volume1/web doesn't contain anything you care about, and delete everything inside it (sudo rm -rf /var/services/web). You may need to chmod permissions for this - I ended up leaving the web directory itself intact, but nothing inside.
Reboot. Mount any encrypted disks, etc.
Check that /var/services/web now shows it is symlinked to /volume1/web, e.g. sudo readlink -e /var/services/web.
Also check permissions for /volume1/web, e.g. ls -al /volume1. It should be owned by root:root and have permissive (777) bits.
Install Web Station, PHP 7.2, and phpMyAdmin in that order.
After this, I could open phpMyAdmin and be served its log in screen.
Debugging notes:
For me, when I SSH in I see in the logs similar issues:
2020/12/17 10:36:35 [error] 32658#32658: *1028 "/var/services/web/phpMyAdmin/index.php" is forbidden (13: Permission denied),
ps says that the nginx workers run as the http user (uid=1023(http) gid=1023(http) groups=1023(http)).
The directory /var/services/web/ appears to be owned by root, both group and user:
# ls -al /var/services/web/
total 424
drwxr-xr-x 3 root root 4096 Dec 17 10:29 .
drwxr-xr-x 3 root root 4096 Dec 17 10:22 ..
-rw-r--r-- 1 root root 27959 Apr 13 2016 adminer.css
-rw-r--r-- 1 root root 82 Apr 13 2016 .htaccess
-rw-r--r-- 1 root root 387223 Apr 13 2016 index.php
drwxr-xr-x 10 root root 4096 Dec 17 10:29 phpMyAdmin
It's not clear to me how Web Station's nginx is intended to work at all given the mismatch - perhaps some set of actions I took prior caused it to decide to install with bad ownership.
I decided to leave everything owned by root, but changed group permissions so that http can access:
# chown -R root:http /var/services/web/
# chmod -R 775 /var/services/web/
This got past the initial error, but revealed a new one:
"/usr/syno/synoman/phpMyAdmin/index.cgi" is not found (2: No such file or directory)
Indeed, there was no trace of phpMyAdmin anywhere in that directory. Evidence of a bad install.
I decided to uninstall anything web related: phpMyAdmin, PHP 7, Apache (happened to be installed), nginx, and Web Station. Once I did, I still had two files in /var/services/web: adminer.css index.php.
I had tried adminer prior to this. In /var/services, there were symlinks to specific volume locations, e.g.:
# ls -al /var/services/
total 12
drwxr-xr-x 3 root root 4096 Dec 17 10:22 .
drwxr-xr-x 17 root root 4096 Dec 17 10:21 ..
lrwxrwxrwx 1 root root 18 Jan 20 2020 download -> /volume1/#download
lrwxrwxrwx+ 1 root root 14 Dec 17 10:22 homes -> /volume1/homes
lrwxrwxrwx 1 root root 24 Jan 20 2020 pgsql -> /volume1/#database/pgsql
lrwxrwxrwx 1 root root 13 Dec 17 10:22 tmp -> /volume1/#tmp
lrwxrwxrwx 1 root root 13 Dec 17 10:22 web
Interestingly, web was not symlinked. I fully deleted /var/services/web.
Looking over at /volume1, I do see a /volume1/web, again fully owned by root but with extremely constrained permission:
d---------+ 1 root root 52 Dec 17 10:14 web
There are only a few things in here, which look related to a blank install of Web Station. I fully deleted everything within /volume1/web, but left it as is. With everything maximally cleaned I rebooted.
Upon boot, /var/services/web was now symlinked to /volume1/web, which now also had useful permission bits (777), and owned by root:root. Maybe this was done by some boot recover process, who knows. (I still have nothing web related installed at this point.)
I installed Web Station, then PHP 7.2, then phpMyAdmin.
I had the same issue when accessing my server via
<name>.local/phpMyAdmin/
It worked when I accessed it via
<local ip>/phpMyAdmin/
Will appreciate if someone can please guide or provide me pointers to debug the backup issues with Artifactory. Whenever backups are performed - there is always an error message of 401 on /api/v1/system/backup/export in the artifactory.log
The backups exist on backup location but with an error message in the log. Not sure how can debug and implications of this error in the logs. I can see in the stack the rest call is failing, have tried setting a password to unsupported and multiple other things but the error persists. Also checked the Jira on Artifactory to no avail. Any pointers will be greatly appreciated
More details
artifactory.version=5.9.3
artifactory.timestamp=1521564024289
artifactory.revision=50903900
artifactory.buildNumber=820
The backups are failing with following the info in the log.
2018-04-24 11:59:24,620 [ajp-apr-8009-exec-9] [ERROR] (o.a.s.a.AccessServiceImpl:1070) - Error during access server backup
org.jfrog.access.client.AccessClientHttpException: HTTP response status 401:Failed on executing /api/v1/system/backup/export, with response: {"errors":[{"code":"UNAUTHORIZED","detail":"Bad credentials","message":"HTTP 401 Unauthorized"}]}
at org.jfrog.access.client.http.AccessHttpClient.createRestResponse(AccessHttpClient.java:154)
at org.jfrog.access.client.http.AccessHttpClient.restCall(AccessHttpClient.java:113)
...
Following is the full stack as displayed in artifactory.log
2018-04-24 11:59:24,620 [ajp-apr-8009-exec-9] [ERROR] (o.a.s.a.AccessServiceImpl:1070) - Error during access server backup
org.jfrog.access.client.AccessClientHttpException: HTTP response status 401:Failed on executing /api/v1/system/backup/export, with response: {"errors":[{"code":"UNAUTHORIZED","detail":"Bad credentials","message":"HTTP 401 Unauthorized"}]}
at org.jfrog.access.client.http.AccessHttpClient.createRestResponse(AccessHttpClient.java:154)
at org.jfrog.access.client.http.AccessHttpClient.restCall(AccessHttpClient.java:113)
at org.jfrog.access.client.system.SystemClientImpl.exportAccessServer(SystemClientImpl.java:21)
at org.artifactory.security.access.AccessServiceImpl.exportTo(AccessServiceImpl.java:1060)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:201)
at com.sun.proxy.$Proxy144.exportTo(Unknown Source)
at org.artifactory.spring.ArtifactoryApplicationContext.exportTo(ArtifactoryApplicationContext.java:662)
at org.artifactory.ui.rest.service.admin.importexport.exportdata.ExportSystemService.execute(ExportSystemService.java:67)
at org.artifactory.rest.common.service.ServiceExecutor.process(ServiceExecutor.java:38)
at org.artifactory.rest.common.resource.BaseResource.runService(BaseResource.java:92)
at org.artifactory.ui.rest.resource.admin.importexport.ExportArtifactResource.exportSystem(ExportArtifactResource.java:65)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$ResponseOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:205)
at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:302)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
at com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:108)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1542)
at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1473)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1419)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1409)
at com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:409)
at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:558)
at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:733)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:292)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
at org.artifactory.webapp.servlet.RepoFilter.execute(RepoFilter.java:184)
at org.artifactory.webapp.servlet.RepoFilter.doFilter(RepoFilter.java:93)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
at org.artifactory.webapp.servlet.AccessFilter.useAuthentication(AccessFilter.java:403)
at org.artifactory.webapp.servlet.AccessFilter.doFilterInternal(AccessFilter.java:212)
at org.artifactory.webapp.servlet.AccessFilter.doFilter(AccessFilter.java:166)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
at org.artifactory.webapp.servlet.RequestFilter.doFilter(RequestFilter.java:67)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
at org.springframework.session.web.http.SessionRepositoryFilter.doFilterInternal(SessionRepositoryFilter.java:164)
at org.springframework.session.web.http.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:80)
at org.artifactory.webapp.servlet.SessionFilter.doFilter(SessionFilter.java:62)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
at org.artifactory.webapp.servlet.ArtifactoryFilter.doFilter(ArtifactoryFilter.java:128)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:212)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:94)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:141)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:620)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:502)
at org.apache.coyote.ajp.AbstractAjpProcessor.process(AbstractAjpProcessor.java:877)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:684)
at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.doRun(AprEndpoint.java:2527)
at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:2516)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:748)
2018-04-24 11:59:24,660 [ajp-apr-8009-exec-9] [INFO ] (o.a.s.ArtifactoryApplicationContext:819) - Note: the etc exported folder has excessive permissions. Be careful with the files.
Thanks for the feedback.
I suspect the reason for the behavior is that for the more common operations Artifactory uses the <adminToken> from the Config Descriptor, however some other operations use credentials saved in $ARTIFACTORY_HOME/etc/security/access/access.creds.
These seem to be bad.
In order to restart these you should:
Create the following file: $ARTIFACTORY_HOME/access/etc/bootstrap.creds
The content of the file should be: access-admin#*=password
The permissions of the file must be 600.
Once that file is in place, restart Artifactory.
Since Artifactory version 5.4 there is a separate service in Artifactory named "Access", which manages permissions and security related configurations.
Artifactory authenticates with Access using an access token that is configured in the "Config Descriptor".
It is possible that this issue will be resolved by a simple restart, so that's what i would have started with.
If this doesn't work, or what i suspect will happen is Artifactory won't be able to start, please do (while Artifactory is shut down):
Remove the <adminToken> tag from the $ARTIFACTORY_HOME/etc/artifactory.config.latest.xml
$ cp artifactory.config.latest.xml artifactory.config.import.xml
Restart Artifactory.
Added bootstrap.creds
tomcat#XXXXXXXX:/home/bitnami/apps/artifactory/artifactory_home/etc$ ls -ltrh
total 136K
-rw-r--r-- 1 tomcat tomcat 5.5K Mar 20 16:41 mimetypes.xml
-rw-r--r-- 1 tomcat tomcat 12K Mar 20 16:41 logback.xml
-rw-r--r-- 1 tomcat tomcat 13K Mar 20 16:41 artifactory.system.properties
-rw-r--r-- 1 tomcat tomcat 11K Mar 20 16:41 artifactory.config.bootstrap.xml
-rw-rw-r-- 1 tomcat tomcat 145 Mar 21 13:36 db.properties
drwxrwxr-x 2 tomcat tomcat 4.0K Mar 21 13:37 ui
drwxrwxr-x 2 tomcat tomcat 4.0K Mar 21 13:37 plugins
drwx------ 3 tomcat tomcat 4.0K Mar 21 13:37 security
-rw-rw-r-- 1 tomcat tomcat 13K Mar 21 13:37
artifactory.config.latest.1521639475000.xml
-rw-r--r-- 1 tomcat tomcat 199 Apr 24 18:50 binarystore.xml
-rw-rw-r-- 1 tomcat tomcat 13K Apr 24 18:57 artifactory.config.latest.xml_bkp
-rw-rw-r-- 1 tomcat tomcat 12K Apr 24 18:58
artifactory.config.latest.1524596291000.xml
-rw-rw-r-- 1 tomcat tomcat 14K Apr 25 14:39 artifactory.config.latest.xml
-rw------- 1 tomcat tomcat 24 Apr 25 15:09 bootstrap.creds
-rw-rw-r-- 1 tomcat tomcat 864 Apr 25 15:12 artifactory.properties
Contents of bootstrap.creds are
access-admin#*=password
AND restarted the arttifactory BUT still seeing the same error message
2018-04-25 15:14:29,607 [art-exec-1] [ERROR] (o.a.s.a.AccessServiceImpl:1070) - Error during access server backup: HTTP response status 401:Failed on executing /api/v1/system/backup/export, with response: {"errors":[{"code":"UNAUTHORIZED","detail":"Bad credentials","message":"HTTP 401 Unauthorized"}]}
I tried the backup using access-admin as well as user from gui with same error (both are admin users).
Following are from the access log when artifactory restarted
2018-04-25 15:10:54,396 [localhost-startStop-1] [INFO ] (o.j.a.c.AccessApplicationContextInitializer:46) - Using JFrog Access home at '/opt/bitnami/apps/artifactory/artifactory_home/access'
2018-04-25 15:10:54,413 [localhost-startStop-1] [INFO ] (o.j.a.AccessApplication:48) - Starting AccessApplication v3.2.2 on ip-10-51-35-238 with PID 16169 (/opt/bitnami/apache-tomcat/webapps/access/WEB-INF/lib/access-application-3.2.2.jar started by tomcat in /opt/bitnami/apache-tomcat/bin)
2018-04-25 15:10:54,414 [localhost-startStop-1] [INFO ] (o.j.a.AccessApplication:597) - The following profiles are active: production,grpc
2018-04-25 15:11:11,402 [localhost-startStop-1] [INFO ] (o.j.a.s.d.u.AccessJdbcHelperImpl:129) - Database: Apache Derby 10.11.1.1 - (1616546). Driver: Apache Derby Embedded JDBC Driver 10.11.1.1 - (1616546)
2018-04-25 15:11:11,410 [localhost-startStop-1] [INFO ] (o.j.a.s.d.u.AccessJdbcHelperImpl:132) - Connection URL: jdbc:derby:/opt/bitnami/apps/artifactory/artifactory_home/data/derby
2018-04-25 15:11:16,127 [localhost-startStop-1] [INFO ] (o.j.a.s.s.c.InternalConfigurationServiceImpl:94) - Loading configuration from db finished successfully
2018-04-25 15:11:18,035 [localhost-startStop-1] [INFO ] (o.j.a.s.s.AccessStartupServiceImpl:79) - Found master.key file at /opt/bitnami/apps/artifactory/artifactory_home/etc/security/master.key, using it as master.key
2018-04-25 15:11:19,486 [localhost-startStop-1] [INFO ] (o.j.a.s.s.t.TokenServiceImpl:100) - Scheduling task for revoking expired tokens using cron expression: 0 0 0/1 * * ?
2018-04-25 15:11:19,651 [localhost-startStop-1] [INFO ] (o.j.a.s.r.c.RpcServiceInvoker:86) - Added service: sync
2018-04-25 15:11:20,764 [localhost-startStop-1] [INFO ] (o.j.a.s.AccessServerBootstrapImpl:93) - [ACCESS BOOTSTRAP] Starting JFrog Access bootstrap...
2018-04-25 15:11:23,381 [localhost-startStop-1] [INFO ] (o.j.a.s.AccessServerBootstrapImpl:146) - [ACCESS BOOTSTRAP] Updating server '509b68e8-48e5-4bba-8ea7-6564c65d5b37' private key finger print to: 63c2f42824ead3169fc13eab66d3d254d25c659ceef5cdeed21c3110f47ee0d3
2018-04-25 15:11:24,164 [localhost-startStop-1] [INFO ] (o.j.a.s.AccessServerBootstrapImpl:108) - [ACCESS BOOTSTRAP] JFrog Access bootstrap finished.
2018-04-25 15:11:30,624 [localhost-startStop-1] [INFO ] (o.j.a.s.s.s.RefreshableScheduledJob:56) - Scheduling heartbeat task to run every 5 seconds
2018-04-25 15:11:43,339 [localhost-startStop-1] [INFO ] (o.j.a.AccessApplication:57) - Started AccessApplication in 53.93 seconds (JVM running for 93.388)
2018-04-25 15:11:47,756 [localhost-startStop-1] [WARN ] (o.a.t.u.s.StandardJarScanner:311) - Failed to scan [file:/opt/bitnami/apache-tomcat/lib/derbyLocale_cs.jar] from classloader hierarchy enter code here
Additionaly I enabled trace on the logs. Following is what I am seeing in
/home/bitnami/apps/artifactory/artifactory_home/access/logs/request.log. Seems the ones with backup call are tagged as coming from anonymous vs |jfrt#01c94cf2cpdmx60xvtsf8j1jy4 for other calls.
2018-04-25T15:49:03.906+0000|127.0.0.1|jfrt#01c94cf2cpdmx60xvtsf8j1jy4|GET|http://127.0.0.1/access/api/v1/groups/|200|0|198|JFrog Access Java Client/3.2.2
2018-04-25T15:50:17.553+0000|127.0.0.1|anonymous|POST|http://127.0.0.1/access/api/v1/system/backup/export|401|0|188|JFrog Access Java Client/3.2.2
2018-04-25T15:50:18.657+0000|127.0.0.1|jfrt#01c94cf2cpdmx60xvtsf8j1jy4|GET|http://127.0.0.1/access/api/v1/users/|200|0|84|JFrog Access Java Client/3.2.2
2018-04-25T15:50:18.733+0000|127.0.0.1|jfrt#01c94cf2cpdmx60xvtsf8j1jy4|GET|http://127.0.0.1/access/api/v1/groups/|200|0|73|JFrog Access Java Client/3.2.2
2018-04-25T15:50:42.823+0000|127.0.0.1|anonymous|POST|http://127.0.0.1/access/api/v1/system/backup/export|401|0|134|JFrog Access Java Client/3.2.2
2018-04-25T15:50:42.995+0000|127.0.0.1|jfrt#01c94cf2cpdmx60xvtsf8j1jy4|GET|http://127.0.0.1/access/api/v1/users/|200|0|114|JFrog Access Java Client/3.2.2
2018-04-25T15:50:43.086+0000|127.0.0.1|jfrt#01c94cf2cpdmx60xvtsf8j1jy4|GET|http://127.0.0.1/access/api/v1/groups/|200|0|64|JFrog Access Java Client/3.2.2
Please let me know if I can provide additional relevant information that can help you to get more insight in my envoirnment. Thank you again for you help
guys i have looked and searched and read. yum update changed a permission somewhere but cant find where. Nagios on centos starts correctly i can view the page but for some reason i dont see any hosts or services, only 403 forbidden in the corner.
ive checked my nagios.cfg and no errors or warnings. I have started Nagios as daemon, same. Any other suggestions ?
total 160
drwxrwxr-x 5 root root 4096 May 7 18:14 .
drwxr-xr-x. 78 root root 4096 May 8 22:38 ..
-rw-rw-r-- 1 root root 11339 Sep 23 2014 cgi.cfg
-rw-rw-r-- 1 root root 11658 Aug 30 2013 cgi.cfg.rpmnew
drwxr-x--- 5 root nagios 4096 Aug 30 2013 conf.d
-rw-rw-r-- 1 root root 43443 Oct 2 2014 nagios.cfg
-rw-rw-r-- 1 root root 44533 Aug 30 2013 nagios.cfg.rpmnew
-rw-r--r-- 1 root root 960 Jul 24 2016 nrpe.cfg
-rw-r--r-- 1 root root 899 Mar 31 2015 nrpe.cfg.rpmsave
-rw-r--r-- 1 root root 5332 Feb 24 2015 nsca.cfg
drwxr-x--- 2 root nagios 4096 May 7 17:39 objects
-rw-r----- 1 root apache 27 Aug 30 2013 passwd
drwxr-x--- 2 root nagios 4096 May 7 18:14 private
-rw-r----- 1 root root 1340 Aug 30 2013 resource.cfg
-rw-r--r-- 1 root root 1628 Mar 20 2013 send_nsca.cfg
the check configuration :
Nagios Core 3.5.1
Copyright (c) 2009-2011 Nagios Core Development Team and Community Contributors
Copyright (c) 1999-2009 Ethan Galstad
Last Modified: 08-30-2013
License: GPL
Website: http://www.nagios.org
Reading configuration data...
Read main config file okay...
Processing object config directory '/etc/nagios/conf.d'...
Processing object config directory '/etc/nagios/conf.d/servicegroups'...
Processing object config file '/etc/nagios/conf.d/servicegroups/jira-servers.cfg'...
Processing object config file '/etc/nagios/conf.d/servicegroups/routers-servers.cfg'...
Processing object config file '/etc/nagios/conf.d/servicegroups/ups-servers.cfg'...
Processing object config file '/etc/nagios/conf.d/servicegroups/backup-servers.cfg'...
Processing object config file '/etc/nagios/conf.d/servicegroups/clone-servers.cfg'...
Processing object config file '/etc/nagios/conf.d/servicegroups/perforce-servers.cfg'...
Processing object config file '/etc/nagios/conf.d/servicegroups/linux-servers.cfg'...
Processing object config file '/etc/nagios/conf.d/servicegroups/web-servers.cfg'...
Processing object config file '/etc/nagios/conf.d/hostgroups.cfg'...
Processing object config directory '/etc/nagios/conf.d/hosts'...
Processing object config file '/etc/nagios/conf.d/hosts/servers.cfg'...
Processing object config file '/etc/nagios/conf.d/hosts/test.cfg'...
Processing object config file '/etc/nagios/conf.d/hosts/diskstation.cfg'...
Processing object config file '/etc/nagios/conf.d/hosts/clone-servers.cfg'...
Processing object config file '/etc/nagios/conf.d/hosts/wifi.cfg'...
Processing object config file '/etc/nagios/conf.d/hosts/cloud.cfg'...
Processing object config file '/etc/nagios/conf.d/hosts/perforce-servers.cfg'...
Processing object config file '/etc/nagios/conf.d/hosts/printers.cfg'...
Processing object config file '/etc/nagios/conf.d/hosts/switches.cfg'...
Processing object config file '/etc/nagios/conf.d/contacts.cfg'...
Processing object config directory '/etc/nagios/conf.d/commands'...
Processing object config file '/etc/nagios/conf.d/commands/notifications.cfg'...
Processing object config file '/etc/nagios/conf.d/commands/perfdata.cfg'...
Processing object config file '/etc/nagios/conf.d/commands/checks.cfg'...
Processing object config file '/etc/nagios/conf.d/commands/nrpe.cfg'...
Processing object config file '/etc/nagios/conf.d/templates.cfg'...
Read object config files okay...
Running pre-flight check on configuration data...
Checking services...
Checked 124 services.
Checking hosts...
Checked 23 hosts.
Checking host groups...
Checked 8 host groups.
Checking service groups...
Checked 8 service groups.
Checking contacts...
Checked 1 contacts.
Checking contact groups...
Checked 1 contact groups.
Checking service escalations...
Checked 0 service escalations.
Checking service dependencies...
Checked 0 service dependencies.
Checking host escalations...
Checked 0 host escalations.
Checking host dependencies...
Checked 0 host dependencies.
Checking commands...
Checked 27 commands.
Checking time periods...
Checked 1 time periods.
Checking for circular paths between hosts...
Checking for circular host and service dependencies...
Checking global event handlers...
Checking obsessive compulsive processor commands...
Checking misc settings...
Total Warnings: 0
Total Errors: 0
Things look okay - No serious problems were detected during the pre-flight check
finally what i see :
what is see
thanks in advance.
Looks like your permissions are all messed up!
When you installed it.. was it from source? If so, did you use the --with-nagios-user= flag during ./configure?
On one of my boxes I have a combination of apache and nagios as the /usr/local/nagios owners. Try this:
chown -R nagios:nagios /usr/local/nagios
chown -R apache:nagios /usr/local/nagios/etc
chmod +x -R /usr/local/nagios/bin /usr/local/nagios/libexec
You'll also want to make sure that the nagios user and group is set in the main configuration file (/usr/local/nagios/etc/nagios.cfg), like this:
nagios_user=nagios
nagios_group=nagios
Also, did you remember to set up your htpasswd file?
htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin
Anyway, hope this helps get you started!
My actual problem is that Nginx is not able to render pages (403 forbidden) despite the permissions being set to 755 for nginx:nginx.
I am using the following command...
[root#wfe1 user1]# strace -p 26934 -e trace=file
Process 26934 attached
stat("/home/user1/site3/index.html", {st_mode=S_IFREG|0755, st_size=6, ...}) = 0
open("/home/user1/site3/index.html", O_RDONLY|O_NONBLOCK) = -1 EACCES (Permission denied)
The output as you can see is Permission Denied. I would like to know which user account was used to access the file? How can I dig in further?
[root#wfe1 user1]# ls -al site3
total 8
drwxr-xr-x. 2 nginx nginx 23 Mar 6 06:12 .
drwx------. 5 user1 user1 4096 Mar 6 06:12 ..
-rwxr-xr-x. 1 nginx nginx 6 Mar 6 06:12 index.html
Take a look in the nginx access logs to see where things are failing
Use ps aux | grep nginx to see which user nginx is running as.
Make sure you have the correct "allow all" permissions set in your nginx config / location stanza.