Go to Linux Permissions

The publishing system architecture diagram is simplified as follows:

The administrator invokes the "publisher (codenamed Varian, hereinafter referred to as Varian)" Through Jenkins, and the publisher will perform a series of initialization operations, build a Docker image onto the Docker repository after completion, update the image of the container cluster, and the user to access our container cluster through load balancing.

The old Varian use Shell+python development, with Jenkins (jdk1.7) to publish, because of internal projects more, write a lot of compatible scripts, code is messy. We plan to refactor the Varian, complete with Python development, each function modular, different types of projects with Lego ideas to assemble the module deployment release, reduce coupling. And to upgrade Jenkins to the latest version, the JDK is also upgraded to 1.8. The new Varian has been developed, and now the test is deployed, and the story begins.

In order to reduce the impact on existing projects, the decision to redeploy a new set of environments, complete testing after the old environment abandoned, directly enable the new environment, the new environment information is as follows:

• System: DEBIAN8
• Language: Python3.4
• JDK1.8 + Jenkins2.134

Troubleshooting the problem with Nginx Access 403

Through the Jenkins call Varian Normal deployment of a static project (pure HTML,CSS,JS and other static resources), through load balancing access to the container cluster (refer to the top of the schema), found that the page style can not be loaded, the browser press F12 to bring up the console found a CSS file return 403 status

Web Services with Nginx, in the mind quickly over what circumstances the Nginx will return 403:

• Nginx configured Whitelist, client Access IP is not in whitelist

allow 192.168.0.152;deny all;

• The path accessed is a directory, and Nginx is configured with a Forbidden column directory

#nginx中这个配置默认就是off，改成on当访问的路径是目录时，可以列出目录中的内容autoindex           off;

• The path accessed is a file, but the user and user groups configured by the Nginx service do not have read access to the file

#nginx中这个配置指定nginx服务的用户和用户组                                                                                                                  user  www-data www-data; 

• Index configuration error, such as your directory is only index.html, you have configured INDEX.SHMTL or index.php, etc.

index index.shtml index.php;

Common have the above problems will cause nginx return 403, quickly troubleshooting, found that the problem caused by permissions, nginx configuration of the user and user group is Www-data, and the CSS file belongs to the main group is root, and other users do not have any permissions

# cat /etc/nginx/nginx.conf                                                                                                                     user  www-data www-data;# ls -lh csl.css -rw-r----- 1 root root 7.9K Jul 24 12:34 csl.css

Here is a detailed explanation of the file permissions under Linux , with the above Csl.css file as an example:

-rw-r----- 1 root root 7.9K Jul 24 12:34 csl.css

Split with spaces

• The first -rw-r----- 10 characters define permissions for a file
  • The first character, - which is represented here as a file, will also be seen as d representing directories, l representing connections
  • The remaining nine characters, each of the three groups, the 第2-4个 character represents the master permission, the 第5-7个 character represents the group permission, and the 第8-10个 character represents the permissions of the other user
  • Each group of three characters are R, W, X, the number of r=4, w=2, X=1, respectively, represents the read, write, execute permissions, if the character has a value indicating that the permission, such as the upper CSS file permissions for the master has RW read and write permissions, the group only R permissions, other users do not have permissions
• The second paragraph is a number that represents the number of connections to the file
• The third segment of Root indicates that the owner of the user is root
• The fourth segment root indicates that the user's group is also root
• The fifth paragraph indicates the file size
• The three paragraph behind is the modified time
• Last paragraph is file name

OK, then the top of the fault said, has been found because the file permissions of the problem caused by 403, then modify the permissions of the file to 644 (other users have Read permission), and again access to return to normal status. Is this the end of the question? Of course not, think carefully about why other file permissions are OK, this file permissions are not right? Then find out why.

Tomcat8 UMASK

After repeated testing, I found that I was working directly under Linux to execute a Python script via the console, and the final file permissions were normal, but the same script was not properly executed after Jenkins.

What is the difference between console execution and Jenkins execution? Account is not the same ah, then the Jenkins project, Tomcat files are changed to belong to the main group are root re-execution, found the same result.

Think about what else is wrong, this CSS file is generated by the program, the resulting file permissions are incorrect, umask! The word suddenly popped out, yes, it should be umask, he controls the ability to generate new files.

A brief description of what is umask:
The Umask value is used to set the default permissions for the user when creating the file, with the Set file Permissions command chmod is relative, a total of four, but we usually only use the latter three bits, also corresponds to the owner group and other users of the permissions, For example, your account Umask value is 0022 (can be viewed directly through the umask command), when you create a file permission defaults to 644 (the initial maximum permissions for the file is 666,umask set to 022, then the final permission is: 6-0,6-2,6-2=644. Of course, some people say that the maximum file permissions is 777, yes, but we are talking about the default permissions, the default permissions are determined by Umask, Umask is set to 000 when the permissions of the file is 666, folder permissions 777), at this time the directory permissions are created 755 (the highest permission for the directory is 777, Umask is set to 022, then the final permission is 7-0,7-2,7-2=755)
- - -

Check the root user's umask, Jenkins User's umask, are 0022, no problem ah, and login these two accounts created a new file permissions are normal, there is a situation jenkins!

Jenkins has no place to configure Umask,jenkins run in the Tomcat container, the old version of Varian also have similar processing logic has been no problem, this time the upgrade tomcat8, tomcat8 updated umask? Doubtful look under, sure enough! TOMCAT8 's umask By default changed to 0027, hemp slipped into 0022, the problem solved smoothly

# vi tomcat/bin/catalina.sh if [ -z "$UMASK" ]; then UMASK="0027"fi

Go to Linux Permissions