I am trying to set a custom umask for a tomcat 8 instance, tried to make it the good way by using the UMask directive in systemd tomcat unit as seen here without luck.
I'd like to set a 022 umask cause the company dev needs to access tomcat / application logs and they are not in the same group as the tomcat user....
the crazy thing is that the systemd doc says :
Controls the file mode creation mask. Takes an access mode in octal notation. See umask(2) for details. Defaults to 0022.
But the logs (application / tomcat) are set to 640 (not the expected 755) :
-rw-r----- 1 top top 21416 Feb 1 09:58 catalina.out
My service file :
# Systemd unit file for tomcat
[Unit]
Description=Apache Tomcat Web Application Container
After=syslog.target network.target
[...]
User=top
Group=top
UMask=0022
[Install]
WantedBy=multi-user.target
Any thoughts about this ?
Thanks
Try adding UMASK as Environment variable into tomcat's service file:
[Service]
...
Environment='UMASK=0022'
...
Default catalina.sh is checking for environment's $UMASK:
# Set UMASK unless it has been overridden
if [ -z "$UMASK" ]; then
UMASK="0027"
fi
umask $UMASK
(It seems to me, that UMask from systemd is not used by Tomcat, but I am not completely sure.)
I think you can achieve this with systemd by doing the following:
~]# mkdir -p /etc/systemd/system/tomcat.service.d
~]# echo -e "[Service]\nUMask=0022" >/etc/systemd/system/tomcat.service.d/custom-umask.conf
~]# systemctl daemon-reload
~]# systemctl restart tomcat
/etc/systemd/system/tomcat.service.d/umask-user.conf should overwrite the default values.
Source: https://access.redhat.com/solutions/2220161
P.S: A umask of 0022 would give a file 0644 permissions and a directory 0755
if using jsvc to start Tomcat as daemon process, then we need to set the -umask argument in jsvc command line
Related
System release: CoreOS 2135.5.0
Kernel: 4.19.50-coreos-r1
System install way: vmware
When I change the port in the sshd.service，it displays:
CoreOS-234 ssh # echo "Port 10000" >> /usr/share/ssh/sshd_config ;systemctl mask sshd.socket;systemctl enable sshd.service;systemctl restart sshd.service
-bash: /usr/share/ssh/sshd_config: Read-only file system
The file system that you are working in is currently in Read-only mode. Remounting the file system to read-write should resolve the issue. You will need to have root privilages:
$ mount -o remount,rw /
Occasionally the reason your file system will be running in read-only mode is due to Kernel issues, therefore there may be further problems with the system that will need to be debugged. Regarding the Kernel errors you may want to have a look at the following link: https://unix.stackexchange.com/questions/436483/is-remounting-from-read-only-to-read-write-potentially-dangerous?rq=1
In coreos /usr is designed to be a read-only file system, Remounting /usr is theoretically feasible, but is not officially recommended
You can refer to this
I use the following command to solve this problem
sudo sed -i '$a\Port=60022' /etc/ssh/sshd_config && \
sudo systemctl mask sshd.socket && \
sudo systemctl enable sshd.service && \
sudo systemctl start sshd.service
i'm facing the next error in a centos 7 server
I take a look to similar questions saying that is because SELinux doesn't allow to httpd to write in my /home folder, i've tried changing the owner of the folder without success; try changing the context (chcon) to httpd_sys_rw_content_t of my /home with the same error; try disabling SELinux and the error persists; and in the file httpd.conf change the User and Group from apache to test this didn't work either. My server is:
LSB Version: :core-4.1-amd64:core-4.1-noarch
Distributor ID: CentOS
Description: CentOS Linux release 7.4.1708 (Core)
Release: 7.4.1708
Codename: Core
and
Linux localhost 3.10.0-693.17.1.el7.x86_64 #1 SMP Thu Jan 25 20:13:58 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
When I execute move_uploaded_file() from php -a as user test it works normally, i see that the issue is with the user apache
TLDR:
Do not run setenforce 0 command, this will disable SELinux! You should not disable SELinux for security reasons.
The solution:
You should update policy to make SELinux allow read and write on specific directories:
To allow apcahe to read and write.
chcon -R -t httpd_sys_rw_content_t /path/your_writabl_dir
For read only directories:
chcon -R -t httpd_sys_content_t /path/yourdir
For example you can make your public (document root) directory read only and only allow write on directories that you allow you app to write on:
# Make all read only
chcon -R -t httpd_sys_content_t /var/www/myapp
# Only allow write on uploads dir for example
chcon -R -t httpd_sys_rw_content_t /var/www/myapp/public/uploads
I'm running a Docker container with CoreOS which uses Debian latest as a base and has various packages installed including supervisor and apache2. I can start and successfully run apache using the following command:
# /usr/bin/pidproxy /var/run/apache2.pid /bin/bash -c "source /etc/apache2/envvars && /usr/sbin/apache2 -DFOREGROUND -k start"
However, when I stick this command in a supervisor config file:
[program:apache2]
command=/usr/bin/pidproxy /var/run/apache2.pid /bin/bash -c "source /etc/apache2/envvars && /usr/sbin/apache2 -DFOREGROUND -k start"
redirect_stderr=true
and do this:
# supervisorctl start apache2
I get back this response:
apache2: ERROR (abnormal termination)
Looking at the supervisor process log file I see the help output from the apache2 command, as if it had been called like so apache2 -h. I have no idea why a command which runs when executed on the command line as root (ssh into the container) would not work when verbatim executed by supervisorctl (run as root).
Any point in the right direction would be greatly appreciated.
Not really sure why, but adding quotes to my option values seems to have done the trick, and allowed me to use apachectl. Must be something with the context in which the command is interpreted, whatever supervisor is doing vs input from a bash prompt. Here's my working config file:
[program:apache2]
command=apachectl -D "FOREGROUND" -k start
redirect_stderr=true
You really want to use this. If you don't use pidproxy, a supervisorctl stop apache will not kill all it's children.
This will also make sure that the container will quit when it gets a SIGTERM instead of waiting for a SIGKILL.
[program:apache]
command=/usr/bin/pidproxy /var/run/apache2/apache2.pid /bin/bash -c "/usr/sbin/apache2ctl -D FOREGROUND"
autorestart=true
This is what works for me (using an ubuntu base image, but that should not matter):
Dockerfile:
# Pull Ubuntu as base image
FROM dockerfile/ubuntu
...
# Install supervisor to allow starting mutliple processes
RUN apt-get -y install supervisor && \
mkdir -p /var/log/supervisor && \
mkdir -p /etc/supervisor/conf.d
RUN mkdir /var/log/supervisord
# Add supervisor configuration
ADD etc/supervisor/supervisor.conf /etc/supervisor.conf
# Install Apache and enable CGI
RUN apt-get install -y apache2
ADD etc/apache/000-default.conf /etc/apache2/sites-available/000-default.conf
RUN a2enmod cgi
....
supervisor.conf
[supervisord]
; supervisord log file
logfile=/var/log/supervisord/supervisord.log
; info, debug, warn, trace
loglevel=debug
; pidfile location
pidfile=/var/run/supervisord.pid
; run supervisord as a daemon
nodaemon=false
; number of startup file descriptors
minfds=1024
; number of process descriptors
minprocs=200
; default user
user=root
; where child log files will live
childlogdir=/var/log/supervisord/
[unix_http_server]
file=/var/run/supervisor.sock ; (the path to the socket file)
; the below section must remain in the config file for RPC
; (supervisorctl/web interface) to work, additional interfaces may be
; added by defining them in separate rpcinterface: sections
[rpcinterface:supervisor]
supervisor.rpcinterface_factory = supervisor.rpcinterface:make_main_rpcinterface
[supervisorctl]
serverurl=unix:///var/run/supervisor.sock ; use a unix:// URL for a unix socket
; Apache server
[program:apache2]
command=/usr/sbin/apache2ctl -D FOREGROUND
environment=APACHE_LOG_DIR=/var/log/apache2
redirect_stderr=true
In CentOS apache is Called httpd not apache2
Your supervisor conf file will need to be updated for CentOS
/usr/sbin/httpd is the program location.
[program:apache2]
command=/usr/bin/pidproxy /var/run/httpd.pid /bin/bash -c "/usr/sbin/httpd -DFOREGROUND -k start"
redirect_stderr=true
The Redis startup script is supposed to create a pid file at startup, but I've confirmed all the settings I can find, and no pid file is ever created.
I installed redis by:
$ yum install redis
$ chkconfig redis on
$ service redis start
In my config file (/etc/redis.conf) I checked to make sure these were enabled:
daemonize yes
pidfile /var/run/redis/redis.pid
And in the startup script (/etc/init.d/redis) there is:
exec="/usr/sbin/$name"
pidfile="/var/run/redis/redis.pid"
REDIS_CONFIG="/etc/redis.conf"
[ -e /etc/sysconfig/redis ] && . /etc/sysconfig/redis
lockfile=/var/lock/subsys/redis
start() {
[ -f $REDIS_CONFIG ] || exit 6
[ -x $exec ] || exit 5
echo -n $"Starting $name: "
daemon --user ${REDIS_USER-redis} "$exec $REDIS_CONFIG"
retval=$?
echo
[ $retval -eq 0 ] && touch $lockfile
return $retval
}
stop() {
echo -n $"Stopping $name: "
killproc -p $pidfile $name
retval=$?
echo
[ $retval -eq 0 ] && rm -f $lockfile
return $retval
}
These are the settings that came by default with the install. Any idea why no pid file is created? I need to use it for Monit.
(The system is RHEL 6.4 btw)
For those experiencing on Debian buster:
Editing
nano /etc/systemd/system/redis.service
and adding this line below redis [Service]
ExecStartPost=/bin/sh -c "echo $MAINPID > /var/run/redis/redis.pid"
It suppose to look like this:
[Service]
Type=forking
ExecStart=/usr/bin/redis-server /etc/redis/redis.conf
ExecStop=/bin/kill -s TERM $MAINPID
ExecStartPost=/bin/sh -c "echo $MAINPID > /var/run/redis/redis.pid"
PIDFile=/run/redis/redis-server.pid
then:
sudo systemctl daemon-reload
sudo systemctl restart redis.service
Check redis.service status:
sudo systemctl status redis.service
The pid file now should appear.
On my Ubuntu 18.04, I was getting the same error.
Error reported by redis (on /var/log/redis/redis-server.log):
# Creating Server TCP listening socket ::1:6379: bind: Cannot assign requested address
This is because I've disabled IPv6 on this host and redis-server package (version 5:4.0.9-1) for Ubuntu comes with:
bind 127.0.0.1 ::1
Editing /etc/redis/redis.conf and removing the ::1 address solves the problem. Example:
bind 127.0.0.1
Edit: As pointed out in the comments (thanks to #nicholas-vasilaki and #tommyalvarez), by default redis only allows connections from localhost. Commenting all the line, using:
# bind 127.0.0.1 ::1
works, but makes redis listen from the network (not only from localhost).
More details can be found in redis configuration file.
Problem was that the user redis did not have permission to create the pid file (or directory it was in). Fix:
sudo mkdir /var/run/redis
sudo chown redis /var/run/redis
Then I killed and restarted redis and sure enough, there was redis.pid
In CentOs 7 i need to add to the file:
$ vi /usr/lib/systemd/system/redis.service
The next line:
ExecStartPost=/bin/sh -c "echo $MAINPID > /var/run/redis/redis.pid"
And then restart the service:
$ sudo systemctl daemon-reload
$ sudo systemctl restart redis.service
Reference:
CentOs 7: Systemd & PID File
i had a similar problem on Debian Buster, systemd complains about the missing PID file, even though the file exists and redis is running.
on my system the solution using "echo $MAINPID > /run/redis/redis.pid" works by accident, although/because the real PID file is set to /run/redis/redis-server.pid (spot the different filenames!) and on my system the content of /run/redis/redis.pid (the one of the echo) was empty.
in a discussion on systemd-devel#lists.freedesktop.org someone writes:
... systemd will add the MAINPID environment variable any time it
knows what the main PID is. It learns this by reading the PID file ...
So by the time ExecStartPost runs, the main PID may or may not be
known.
having an empty MAINPID environment variable can be even harmful: if you notice the different PID filenames in the suggested solution, and correct it, you may end up in a situation where the PID file written by redis gets overwritten by an empty file. this happened to me, the result was that systemctl start redis.service never finished.
i also noticed that another server with 100% same OS and configuration, but different hardware did not have this problem.
my conclusion is that it just hits some sort of race condition, systemd seems to look for a PID file just a little too early. on my system, whatever command i used as ExecStartPost, it will add enough delay to make the error disappear.
therefore a solution is to use "sleep 1" (sleep 0.1 works too, but 1 second may be on the safe side):
ExecStartPost=/bin/sleep 1
/etc/systemd/system/redis.service now looks like:
[Service]
Type=forking
ExecStart=/usr/bin/redis-server /etc/redis/redis.conf
ExecStartPost=/bin/sleep 1
ExecStop=/bin/kill -s TERM $MAINPID
PIDFile=/run/redis/redis-server.pid
...
an alternative solution is to use "supervised systemd":
/etc/redis/redis.conf:
# If you run Redis from upstart or systemd, Redis can interact with your
# supervision tree. Options:
# supervised no - no supervision interaction
# supervised upstart - signal upstart by putting Redis into SIGSTOP mode
# supervised systemd - signal systemd by writing READY=1 to $NOTIFY_SOCKET
# supervised auto - detect upstart or systemd method based on
# UPSTART_JOB or NOTIFY_SOCKET environment variables
# Note: these supervision methods only signal "process is ready."
# They do not enable continuous liveness pings back to your supervisor.
supervised systemd
override the redis-server.service file using:
systemctl edit redis-server.service
and enter the following:
[Service]
Type=notify
reload the service and the error should be gone:
sudo systemctl restart redis.service
sudo systemctl status redis.service
Here from 2018
Before start, I am on Ubuntu 18.04.I wrote this if anyone comes here
by searching same error.
In my case error is the same but problem is so different. No solutions that proposed here worked.
So I checked logs if they are exist and looked for is there anything useful. Found them on;
cat /var/log/redis/redis-server.log
Searched logs and found that problem is that another service is listening same port.
2963:C 21 Sep 11:07:33.007 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
2963:C 21 Sep 11:07:33.008 # Redis version=4.0.9, bits=64, commit=00000000, modified=0, pid=2963, just started
2963:C 21 Sep 11:07:33.008 # Configuration loaded
2974:M 21 Sep 11:07:33.009 # Creating Server TCP listening socket 127.0.0.1:6379: bind: Address already in use
I checked who is listening.
netstat anp | grep 6379
Found it.
tcp6 0 0 :::6379 :::* LISTEN 3036/docker-proxy
It was docker image of redis that installed by another tool
root#yavuz:~# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
a6a94d401700 redis:3.2 "docker-entrypoint.s…" 20 hours ago Up 3 hours 0.0.0.0:6379->6379/tcp incubatorsuperset_redis_1
So I stopped docker image
root#yavuz:~# docker stop incubatorsuperset_redis_1
And redis-server started without problem.
root#yavuz:~# systemctl start redis-server
root#yavuz:~# systemctl status redis-server
● redis-server.service - Advanced key-value store
Active: active (running) since Fri 2018-09-21 11:10:34 +03; 1min 49s ago
Process: 3671 ExecStart=/usr/bin/redis-server /etc/redis/redis.conf (code=exited, status=0/SUCCESS)
For CentOS:
In my case name of Redis server is redis.service, start it edit
systemctl edit redis.service
Add this:
[Service]
ExecStartPost=/bin/sh -c "echo $MAINPID > /var/run/redis/redis.pid"
PIDFile=/var/run/redis/redis.pid
Im my case it create file: /etc/systemd/system/redis.service.d/override.conf
After restart service:
systemctl daemon-reload
systemctl restart redis
And the pid file is:
cat /var/run/redis/redis.pid
=> 19755
sudo nano /etc/redis/redis.conf
Inside the file, find the supervised directive. This directive allows you to declare an init system to manage Redis as a service, providing you with more control over its operation. The supervised directive is set to no by default. Since you are running Ubuntu, which uses the systemd init system, change this to systemd.
My default, Redis does not run as a daemon, and that is why it does not create a pid file. If you look at /etc/redis/redis.conf, it says so explicitly under General.
#By default Redis does not run as a daemon. Use 'yes' if you need it...
daemonize no
So all you need to do is to change it to daemonize yes
For people struggling with getting it to work on Ubuntu 18.04 you need to edit /etc/redis/redis.conf and update the pidfile declaration to following:
pidfile "/var/run/redis/redis-server.pid"
Ubuntu 18. /var/run/redis had the wrong permissions:
drwxr-sr-x 2 redis redis 60 Apr 27 12:22 redis
Changed to 755 (drwxrwxr-x) and the pid file now appears.
How do I set the httpd and mysqld services to start automatically upon booting an amazon-ec2 instance?
Currently I have to start them manually by connecting to the instance via ssh and running sudo service httpd start and sudo service mysqld start.
Rather than starting over with a new AMI, you could just issue the following commands on an Amazon Linux EC2 instance...
sudo chkconfig mysqld on
sudo chkconfig httpd on
You can check the settings before & after enabling these services to start on boot using the following commands...
sudo chkconfig --list mysqld
sudo chkconfig --list httpd
See all services using just...
sudo chkconfig --list
NOTE: If you are having any trouble with chkconfig being in root's path, you can try specifying the full path like this...
sudo /sbin/chkconfig mysqld on
sudo /sbin/chkconfig httpd on
It is different between Amazon Linux 1 and Amazon Linux 2.
Amazon Linux 1
In AmazonLinux1, use chkconfig command.
$ sudo chkconfig mysqld on
$ sudo chkconfig httpd on
Amazon Linux2
In AmazonLinux2, systemd was introduced. So, chkconfig is legacy command. You should use systemctl. It is a control command for systemd.
$ sudo systemctl enable mysqld
$ sudo systemctl enable httpd
You can confirm it is enabled or not using by is-enabled command.
$ sudo systemctl is-enabled mysqld
enabled
chkconfig command request will be forwarded to systemctl.
$ chkconfig mysqld on
Note: Forwarding request to 'systemctl enable mysqld.service'.
If you using Amazon Linux 2 AMI you need to follow these steps:
In AMI2 they are using systemctl for managing services check if it is installed on your machine
2.systemctl list-units --type=service by this command check if tomcat.service is listed
sudo systemctl enable tomcat.service To eanable tomcat start on boot up
systemctl is-enabled tomcat.service To check if tomcat enabled to start on boot up linux system
After that you can reboot your linux system and tomcat will be started.
For more about systemctl Click Here
One of my client wants to do this task and I have successfully done by using following way.
Following commands starts the services automatic when instance started.
Auto start apache/httpd
1) systemctl enable httpd
Auto start redis service
2) systemctl enable redis
I have set SELINUX set to disabled in
3) /etc/sysconfig/selinux
For mysql services
sudo chkconfig mysqld on
sudo chkconfig httpd on
I faced the similar problem, here is the solution i am suggesting,
you need to create a file under /etc/init.d directory, e.g with name tomcat, and change the JAVA_HOME and CATALINA_HOME parameters as per your system installation.
Once you do setup this file then run the below command:
sudo chkconfig <file-name> on
where is the file you have created in /etc/init.d it is tomcat in my case.
[ec2-user#ip-<myip> init.d]$ cat tomcat
#!/bin/bash
# description: Tomcat Start Stop Restart
# processname: tomcat
# chkconfig: 234 20 80
JAVA_HOME=/opt/apache-tomcat-7.0.96
export $JAVA_HOME
PATH=$JAVA_HOME/bin:$PATH
export PATH
CATALINA_HOME=/opt/apache-tomcat-7.0.96
case $1 in
start)
sh $CATALINA_HOME/bin/startup.sh
;;
stop)
sh $CATALINA_HOME/bin/shutdown.sh
;;
restart)
sh $CATALINA_HOME/bin/shutdown.sh
sh $CATALINA_HOME/bin/startup.sh
;;
esac
exit 0
chmod 755 tomcat
chkconfig --add tomcat
chkconfig --level 234 tomcat on
chkconfig --list tomcat
service tomcat start
ReactJS on Amazon Linux2 process:
Installing ReactJS on EC2 and running the app at boot:
Once you connect to EC2 instance install NodeJS. Follow this tutorial:
https://docs.aws.amazon.com/sdk-for-javascript/v2/developer-guide/setting-up-node-on-ec2-instance.html
Install httpd server using this tutorial: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Tutorials.WebServerDB.CreateWebServer.html
I used Git Clone to clone the ReactJS app on to /home/ec2-user.
Install Yarn using the command “npm install yarn -g”
Execute the following commands in the cloned project: “Yarn” and then “Yarn build”
Now Copy the build folder using : cp -a /build/. /var/www/html/
Now go to the /var/www/html/ here create a .htaccess file using vi and include the following content: “Options -MultiViews
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^ index.html [QSA,L]”
Save the file with :wq
Now in /etc/httpd/conf/httpd.conf search for Directory with “/var/www/html” attribute and change “AllowOverride None” to “AllowOverride All”. Now open the browser and enter http://ec2-ip or http://ec2-url you will see the default page
Enter the command “systemctl enable httpd” and then “systemctl start httpd” on AmazonLinux2. Now you can access the app on boot rather than running the app again and again.
You are complete.
The best way on Amazon Linux 2 is to use the following bash script on creation. This will install the updates, start Apache2, make it listed as a service so that it automatically restarts upon reboot, and the creation of an index.html and health.html sample files. Configuring a health page is important for application loadbalancers and for autoscaling groups.
#!/bin/bash
yum update -y
yum install httpd -y httpd-tools mod_ssl
service httpd start
chkconfig httpd on
systemctl start httpd
systemctl enable httpd
echo "Hello, World, from your Webserver on Amazon Linux" > /var/www/html/index.html
echo "Healthy" > /var/www/html/health.html
Cheers!
Either use any of the preexisting LAMP AMI, it will have both of them running as service already.
One example is BitNami, you will find several other when you fire an ec2 instance.