I'm trying to apply a salt state to my non prod environment at /srv/salt/non-prod
I'm getting this result:
[root#salt non-prod]# salt '*' state.apply
salt.localdomain:
----------
ID: states
Function: no.None
Result: False
Comment: No Top file or external nodes data matches found.
Changes:
Summary for salt.localdomain
------------
Succeeded: 0
Failed: 1
I have this location defined in my master config
non-prod:
- /srv/non-prod
- /srv/salt/non-prod/services
- /srv/salt/non-prod/states
I have a top file located here:
[root#salt ~]# cat /srv/salt/non-prod/top.sls
base:
'*':
- apache
- python
- ssh
- users
These are the contents of the non-prod directory
[root#salt ~]# ls -lh /srv/salt/non-prod/
total 16K
drwxr-xr-x. 2 root root 4.0K Oct 3 21:02 apache
drwxr-xr-x. 2 root root 45 Oct 3 20:57 python
drwxr-xr-x. 2 salt salt 6 Oct 3 14:10 services
drwxr-xr-x. 2 root root 54 Oct 3 18:23 ssh
drwxr-xr-x. 2 salt salt 6 Oct 3 14:10 states
-rw-r--r--. 1 root root 80 Oct 3 15:29 state.template
-rw-r--r--. 1 root root 174 Oct 3 15:30 test.sls
-rw-r--r--. 1 root root 61 Oct 3 21:14 top.sls
drwxr-xr-x. 2 root root 22 Oct 3 21:03 users
drwxr-xr-x. 2 salt salt 99 Oct 3 18:28 webserver
it contains a few salt modules
How can I apply salt states to just the non-prod environment?
If you check the syntax using some yaml validation tools, then we can go to next step.
Read saltstack top documentation thoroughly, you will notice setting different environment, you first explicitly define alternate environment name on /etc/salt/master and also specify it under top.sls
i.e., you file_roots specify the non-prod environment
file_roots:
#non-prod environment
non-prod:
- /srv/non-prod
- /srv/salt/non-prod/services
- /srv/salt/non-prod/states
Thus your top.sls should use the environment name non-prod , not base
non-prod:
'*':
- apache
- python
- ssh
- users
Since saltstack always use "base" environment by default, you should apply the state explicitly.
salt '*' state.highstate saltenv=non-prod
Related
I am running Suricata in IDS (af-packet) mode on Ubuntu 20.04.5 LTS (Focal Fossa) and deployed as the root user:
NAME="Ubuntu"
VERSION="20.04.5 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.5 LTS"
VERSION_ID="20.04"
Following the Suricata "Adding your own Rules" Doc, I have added a very basic (for complexity ease when troubleshooting) alerting-rule with first available sid:1000000 from custom rules range:
########### Test Rules #############
alert ssh any any -> xxx.xxx.60.6 !22 (msg:"SSH TRAFFIC on non-SSH port"; flow:to_client, not_established; classtype: misc-attack; target: dest_ip; sid:1000000;)
The .rules file for the local rules has sufficient permissions and matches suricata.rules, owned by root:
ls -halt /var/lib/suricata/rules/
total 22M
-rw-r--r-- 1 root root 3.2K Oct 17 00:00 classification.config
drwxr-x--- 2 root root 4.0K Oct 17 00:00 .
-rw-r--r-- 1 root root 22M Oct 17 00:00 suricata.rules
-rw-r--r-- 1 root root 210 Oct 13 21:45 local.rules
Ensured that the rules are added to Suricata suricata.yaml config and processed is restarted:
cat /etc/suricata/suricata.yaml | grep "rule-files" -A 5 -B 5
##
#default-rule-path: /var/lib/suricata/rules
default-rule-path: /etc/suricata/rules
rule-files:
- suricata.rules
- /var/lib/suricata/rules/local.rules
- /etc/suricata/rules/*.rules
AFAIK, the custom ruleset should be loaded into the suricata.rules file? Therefore, I am running the following verification subject to what I am reporting:
cat /var/lib/suricata/rules/suricata.rules | grep sid:1000000
I can test traffic and verify with tcpdump, matching the rule but never see a signature match in fast.log (which is logging other signature-matching traffic):
cat /var/log/suricata/fast.log | grep 1000000
I see no errors following statup of the service that would indicate an error present:
systemctl status suricata.service
● suricata.service - LSB: Next Generation IDS/IPS
Loaded: loaded (/etc/init.d/suricata; generated)
Active: active (running) since Mon 2022-10-17 13:11:39 UTC; 8h ago
Docs: man:systemd-sysv-generator(8)
Process: 2184275 ExecStart=/etc/init.d/suricata start (code=exited, status=0/SUCCESS)
Tasks: 78 (limit: 618963)
Memory: 25.2G
CGroup: /system.slice/suricata.service
└─2184295 /usr/bin/suricata -c /etc/suricata/suricata.yaml --pidfile /var/run/suricata.pid --af-packet -D -v>
Oct 17 13:11:39 sec3 systemd[1]: Starting LSB: Next Generation IDS/IPS...
Oct 17 13:11:39 sec3 suricata[2184275]: Starting suricata in IDS (af-packet) mode... done.
Oct 17 13:11:39 sec3 systemd[1]: Started LSB: Next Generation IDS/IPS.
Can somebody help me with somewhere I may be silly here?
TYIA!
I want to use a gluster replication volume for sqlite db storage
However, when the '.db' file is updated, LINUX does not detect the change, so synchronization between bricks is not possible.
Is there a way to force sync?
It is not synchronized even if you use the gluster volume heal command.
< My Gluster volume status >
[root#be-k8s-worker-1 common]# gluster volume create sync_test replica 2 transport tcp 10.XX.XX.X1:/home/common/sync_test 10.XX.XX.X2:/home/common/sync_test
Replica 2 volumes are prone to split-brain. Use Arbiter or Replica 3 to avoid this. See: http://docs.gluster.org/en/latest/Administrator%20Guide/Split%20brain%20and%20ways%20to%20deal%20with%20it/.
Do you still want to continue?
(y/n) y
volume create: sync_test: success: please start the volume to access data
[root#be-k8s-worker-1 common]# gluster volume start sync_test
volume start: sync_test: success
[root#be-k8s-worker-1 sync_test]# gluster volume status sync_test
Status of volume: sync_test
Gluster process TCP Port RDMA Port Online Pid
------------------------------------------------------------------------------
Brick 10.XX.XX.X1:/home/common/sync_test 49155 0 Y 1142
Brick 10.XX.XX.X2:/home/common/sync_test 49155 0 Y 2134
Self-heal Daemon on localhost N/A N/A Y 2612
Self-heal Daemon on 10.XX.XX.X1 N/A N/A Y 4257
Task Status of Volume sync_test
------------------------------------------------------------------------------
There are no active volume tasks
< Problem Case >
[root#be-k8s-worker-1 sync_test]# ls -al ## client 1
total 20
drwxrwxrwx. 4 root root 122 Oct 17 10:51 .
drwx------. 8 sbyun domain users 4096 Oct 17 10:50 ..
-rw-r--r--. 1 root root 0 Oct 17 10:35 test
-rwxr--r--. 1 sbyun domain users 16384 Oct 17 10:52 test.d
[root#be-k8s-worker-1 sync_test2]# ls -al ## client2
total 20
drwxrwxrwx. 4 root root 122 Oct 17 10:51 .
drwx------. 8 sbyun domain users 4096 Oct 17 10:50 ..
-rw-r--r--. 1 root root 0 Oct 17 10:35 test
-rwxr--r--. 1 sbyun domain users 16384 Oct 17 10:52 test.db
## diff -> No result
[root#be-k8s-worker-1 user]# diff sync_test/test.db sync_test2/test.db
But if I compare same file in windows
compare on windows
My SQLite database was set to WAL mode. So the wal file was being updated and the .db file was not immediately synced.
I turned off WAL Mode with this command:
PRAGMA journal_mode=DELETE;
I confirmed that it was synced immediately.
According to Sqlite document, It doesn't work over a network file system.
All processes using a database must be on the same host computer; WAL does not work over a network filesystem.
I have a VueJS app hosted on Firebase, and I'm using CloudBuild to build and deploy it. My ultimate goal is to embed a version number or commit SHA into the footer of the front page, so we can always confirm which version we're seeing in the browser. Happy to hear alternate implementations, but right now I'm just trying to write a static text file.
I know each step in CloudBuild is a unique container, and only /workspace gets held over through each step. If I execute "pwd," I do see that's where all these steps take place.
I can even write the text file as shown (my date interpolation doesn't work), and see the file exists in the subsequent step. But after the final deployment, it's not there.
- name: gcr.io/cloud-builders/gcloud
entrypoint: /bin/bash
args: ['-c', "echo \"$REVISION_ID (commit $COMMIT_SHA) deployed on `date`\" >> ./static/version.txt"]
- name: 'bash'
args: ['ls', '-lart', './static']
# Deploy
- name: 'gcr.io/cloud-builders/npm:node-10.10.0'
args: ['run', 'deploy']
the ls output shows this:
total 56
drwxr-xr-x 2 root root 4096 Apr 17 20:52 svg
drwxr-xr-x 2 root root 4096 Apr 17 20:52 styles
drwxr-xr-x 2 root root 4096 Apr 17 20:52 plugins
-rw-r--r-- 1 root root 442 Apr 17 20:52 manifest.json
drwxr-xr-x 2 root root 4096 Apr 17 20:52 legal
drwxr-xr-x 2 root root 4096 Apr 17 20:52 js
drwxr-xr-x 4 root root 4096 Apr 17 20:52 images
drwxr-xr-x 2 root root 4096 Apr 17 20:52 gifs
drwxr-xr-x 3 root root 4096 Apr 17 20:52 fonts
-rw-r--r-- 1 root root 6148 Apr 17 20:52 .DS_Store
drwxr-xr-x 12 root root 4096 Apr 17 20:59 ..
-rw-r--r-- 1 root root 132 Apr 17 21:00 version.txt
drwxr-xr-x 10 root root 4096 Apr 17 21:00 .
So I know the version.txt file gets written and persists across steps.
The npm run deploy step just runs firebase deploy. The app deploys, but the version.txt file gives a 404. Notably, I can navigate to <APP_ROOT>/static/manifest.json and open that file in the browser -- but since it is part of the git revision, maybe that doesn't tell me much.
Not sure how to proceed from here. Am I missing something about how CloudBuild works? Is there a better way to do this version thing?
My username (let’s call it my_name) belongs to the Apache group which is owner of var/www/html directory, sub-directories and files contained within.
In that directory I installed Wordpress. Directories and files permissions are set to 0775 (yeah, I know the files should have 644, but it is not a factor for now).
Well, my username has writing permissions indeed, because I am able to create new files or directories, as well as delete them, by using SSH terminal or WinSCP.
The problem comes up when I run a post-receive hook of a bare git repository, no matter if by running the script or by pushing changes from the local working repository.
In any scenario, the post-receive hook does not work because of permission denied. Really strange and I cannot understand why.
Could you help me please?
Edit:
This is the output of ls -alrth ~/git/devsite.git/hooks directory:
-rwxrwxr-x 1 name apache 896 Apr 2 22:41 commit-msg.sample
-rwxrwxr-x 1 name apache 727 Apr 7 09:09 post-receive
-rwxrwxr-x 1 name apache 189 Apr 2 22:41 post-update.sample
-rwxrwxr-x 1 name apache 398 Apr 2 22:41 pre-applypatch.sample
-rwxrwxr-x 1 name apache 1704 Apr 2 22:41 pre-commit.sample
-rwxrwxr-x 1 name apache 1239 Apr 2 22:41 prepare-commit-msg.sample
-rw-rw-r-- 1 name apache 1348 Apr 2 22:41 pre-push.sample
-rwxrwxr-x 1 name apache 4951 Apr 2 22:41 pre-rebase.sample
-rwxrwxr-x 1 name apache 3611 Apr 2 22:41 update.sample
This is the post-receive script:
#!/bin/sh
TARGET=/var/www/html/wp-content
GIT_DIR=/home/name/git/devsite.git
#run 'post-receive' hook
git --work-tree=$TARGET --git-dir=$GIT_DIR checkout -f
Try again after a
cd /path/tp/bare/repo
git config core.sharedRepository true
I mentioned it before in "Permissions with Git Post-Receive".
In the OP's instance, the post-receive script is not placed properly: it should be in ~/git/devsite.git/hooks, not ~/git/devsite.git.
I have installed Redis 3.0.6 on Debian. There's a /etc/init.d/redis file which starts the Redis server when the system starts or I can invoke it manually to start/stop the server. Problem is that this script is run as root user.
I have a redis user and group that I want to make Redis run under. But I can't figure out how (I have not found an option to make Redis switch user ID after startup). In my config file I use
unixsocket /home/redis/redis.sock
unixsocketperm 770
But, of course, the redis.sock is owned by root.
drwxr-xr-x 2 redis redis 4096 Jan 18 03:34 bin
drwxr-xr-x 2 redis redis 4096 Jan 18 03:55 data
-rw-r--r-- 1 redis redis 41638 Jan 18 03:52 redis.conf
-rw-r--r-- 1 redis redis 16348 Jan 18 03:55 redis.log
-rw-r--r-- 1 root root 5 Jan 18 03:55 redis.pid
srwxrwx--- 1 root root 0 Jan 18 03:55 redis.sock
And the process is, too.
root 7913 0.1 0.1 38016 1976 ? Ssl 03:55 0:00 /home/redis/bin/redis-server *:6379
Ultimately, I have a git user that is also in the redis group and thus should in the end have access to redis.sock. (This is for a manual deployment of GitLab CE).
How I can I configure the Redis server that way?
Update your /etc/init.d to use sudo during start service (line 33):
sudo -u redis $EXEC $CONF
You may need to cleanup old files (in /var/lib) or reset their permission to redis.