saltstack: is there a way to stop updating cron files every time state.highstate is run - linux

Currently I have the following cron.file formula
date > system_cron:
cron.file:
- name: salt://crons/cron_jobs
- source_hash: "md5sum=895dcbbddd27bfa77056ef8c8340549a"
- user: security
But this updates the crontab each time the highstate is run event though the cron_jobs file has not changed and hence the state is the same.
Is there a way to stop creating temp crontab file each time highstate is run when using cron.file

I found that this happens when you have blank lines at the end of the file, or if you have dos line endings instead of unix line endings. Once this has been changed, the file will only be updated when it has changed.
Please note: as you have placed the file in "salt://", you don't need source_hash. This is only required for remote (i.e. http) files.

Related

diff showing only the diff color without change code

I have changed line of a sql file file. But the diff only shows the diff colour without any change code.
the line is: #enabled=0, before the change we had 1 instead of 0.
without the gitattribute
*.sql text diff
I get the error message that file suppressed by a .gitattributes entry or the file's encoding is unsupported.
[this is the link of the image of my git diff] (https://i.stack.imgur.com/bgMvv.png)
You need to check your git status (assuming the #enabled=0 was done on your workstation)
Check if:
the file is indeed Test/Scripts/ScriptsIgnoredOnImport.sql
there is any local commit which would not have been pushed yet.
The file on GitHub can also tell you more, by typing b (which triggers the file "blame" view on GitHub).
As shown here, you can then "View blame prior to this change" and see if your #enabled= was visible then.
As noted by torek, you could have a difference in encoding as well.
As I mentioned in "How do I determine file encoding?", you can (even in a simple CMD on Windows), check the encoding of your current file with:
git show :your/file.sql | file -
# compare it with the previous version
git show #~your/file.sql | file -

How do I use Nagios to monitor a log file that generates a random ID

This the log file that I want to monitor:
/test/James-2018-11-16_15215125111115-16.15.41.111-appserver0.log
I want Nagios to read it this log file so I can monitor a specific string.
The issue is with 15215125111115 this is the random id that gets generated
Here is my script where the Nagios is checking for the Logfile path:
Veriables:
HOSTNAMEIP=$(/bin/hostname -i)
DATE=$(date +%F)
..
CHECK=$(/usr/lib64/nagios/plugins/check_logfiles/check_logfiles
--tag='failorder' --logfile=/test/james-${date +"%F"}_-${HOSTNAMEIP}-appserver0.log
....
I am getting the following output in nagios:
could not find logfile /test/James-2018-11-16_-16.15.41.111-appserver0.log
15215125111115 This number is always generated randomly but I don't know how to get nagios to identify it. Is there a way to add a variable for this or something? I tried adding an asterisk "*" but that didn't work.
Any ideas would be much appreciated.
--tag failorder --type rotating::uniform --logfile /test/dummy \
--rotation "james-${date +"%F"}_\d+-${HOSTNAMEIP}-appserver0.log"
If you add a "-v" you can see what happens inside. Type rotating::uniform tells check_logfiles that the rotation scheme makes no difference between current log and rotated archives regarding the filename. (You frequently find something like xyz..log). What check_logfile does is to look into the directory where the logfiles are supposed to be. From /test/dummy it only uses the directory part. Then it takes all the files inside /test and compares the filenames with the --rotation argument. Those files which match are sorted by modification time. So check_logfiles knows which of the files in question was updated recently and the newest is considered to be the current logfile. And inside this file check_logfiles searches the criticalpattern.
Gerhard

Hide username and computer name from Git Bash for Windows 10

Is there any way to remove the username and computer name from Git Bash for Window 10?
I already checked this : https://github.com/Maximus5/ConEmu/issues/199
But didn't understand how to do that.
Follow the steps below:
Go to C:\Program Files\Git\etc\profile.d\ folder
Find and open the git-prompt.sh file in your favorite text editor
Go to line number 15
Replace the whole line with PS1="$PS1"''
That's it. Start/Restart Git Bash and you should see the username and computer name is gone.
NOTE: You can also hide the annoying MINGW64 text by commenting out the line number 16 and 17 of the same file. To comment out those lines just add a # to the beginning of the line. That's it. Now start/restart Git Bash and it should go away.
Better way!!
Follow the steps as mentioned by #Saabbir, with one big change:
# 👇 comment out the wrapping if-else block
if test -f ~/.config/git/git-prompt.sh
then
. ~/.config/git/git-prompt.sh
else
# 👇 leave the content uncommented
...
fi
Save the file, git-prompt.sh using Save As (in your editor) in this path C:\Users\{current_windows_user}\.config\git
Explanation: You can see on line number 8 that it checks for the same file on ~/.config/git. So it's better to update the config file rather than the actual settings file.

zip command not working

I am trying to zip a file using shell script command. I am using following command:
zip ./test/step1.zip $FILES
where $FILES contain all the input files. But I am getting a warning as follows
zip warning: name not matched: myfile.dat
and one more thing I observed that the file which is at last in the list of files in a folder has the above warning and that file is not getting zipped.
Can anyone explain me why this is happening? I am new to shell script world.
zip warning: name not matched: myfile.dat
This means the file myfile.dat does not exist.
You will get the same error if the file is a symlink pointing to a non-existent file.
As you say, whatever is the last file at the of $FILES, it will not be added to the zip along with the warning. So I think something's wrong with the way you create $FILES. Chances are there is a newline, carriage return, space, tab, or other invisible character at the end of the last filename, resulting in something that doesn't exist. Try this for example:
for f in $FILES; do echo :$f:; done
I bet the last line will be incorrect, for example:
:myfile.dat :
...or something like that instead of :myfile.dat: with no characters before the last :
UPDATE
If you say the script started working after running dos2unix on it, that confirms what everybody suspected already, that somehow there was a carriage-return at the end of your $FILES list.
od -c shows the \r carriage-return. Try echo $FILES | od -c
Another possible cause that can generate a zip warning: name not matched: error is having any of zip's environment variables set incorrectly.
From the man page:
ENVIRONMENT
The following environment variables are read and used by zip as described.
ZIPOPT
contains default options that will be used when running zip. The contents of this environment variable will get added to the command line just after the zip command.
ZIP
[Not on RISC OS and VMS] see ZIPOPT
Zip$Options
[RISC OS] see ZIPOPT
Zip$Exts
[RISC OS] contains extensions separated by a : that will cause native filenames with one of the specified extensions to be added to the zip file with basename and extension swapped.
ZIP_OPTS
[VMS] see ZIPOPT
In my case, I was using zip in a script and had the binary location in an environment variable ZIP so that we could change to a different zip binary easily without making tonnes of changes in the script.
Example:
ZIP=/usr/bin/zip
...
${ZIP} -r folder.zip folder
This is then processed as:
/usr/bin/zip /usr/bin/zip -r folder.zip folder
And generates the errors:
zip warning: name not matched: folder.zip
zip I/O error: Operation not permitted
zip error: Could not create output file (/usr/bin/zip.zip)
The first because it's now trying to add folder.zip to the archive instead of using it as the archive. The second and third because it's trying to use the file /usr/bin/zip.zip as the archive which is (fortunately) not writable by a normal user.
Note: This is a really old question, but I didn't find this answer anywhere, so I'm posting it to help future searchers (my future self included).
eebbesen hit the nail in his comment for my case (but i cannot vote for comment).
Another possible reason missed in the other comments is file exceeding the file size limit (4GB).
I converted my script for unix environment using dos2unix command and executed my script as ./myscript.sh instead bash myscript.sh.
I just discovered another potential cause for this. If the permissions of the directory/subdirectory don't allow the zip to find the file, it will report this error. Actually, if you run a chmod -R 444 on the directory, and then try to zip it, you will reproduce this error, and also have a "stored 0%" report, like this:
zip warning: name not matched: borrar/enviar
adding: borrar/ (stored 0%)
Hence, try changing the permissions of the file. If you are trying to send them through email, and those email filters (like Gmail's) invent silly filters of not sending executables, don't forget that making permissions very strict when making zip compression can be the cause of the error you are reporting, of "name not matched".
spaces are not allowed:
it would fail if there are more than one files(s) in $FILES unless you put them in loop
I also encountered this issue. In my case, the line separate is CRLF in my zip shell script which causes the problem. Using LF fixed it.

How to replace the contents of the current buffer with the contents of a file?

I have an external script that takes a Javascript file and automatically fixes some style issues, I want to apply it to the current buffer right before writing (BufWritePre,FileWritePre).
So my idea is to:
w /tmp/foo Write the current buffer contents to a temporary file
silent !fixStyle /tmp/foo Run the script on that file.
Replace the contents of the current buffer with the contents of /tmp/foo
The thing is that I don't know how to do the third step.
One way is deleting current contents (1,$d, i.e., delete between line 1 and last line), and read in the target file starting from line 0 (before line 1 so that there is no blank line):
:1,$d|0r ~/.hck/input
Another way is using a filter (cat in this case) to replace all of the content (%) with the output of the filter:
:%!cat /tmp/foo
You could use set autoread. It detects when the file has been changed on disk and reloads the current buffer from the file. So you could save the file, run the script and vim will reload the buffer with the change contents.
Autoread's help is copied below
*'autoread'* *'ar'* *'noautoread'* *'noar'*
'autoread' 'ar' boolean (default off)
global or local to buffer |global-local|
{not in Vi}
When a file has been detected to have been changed outside of Vim and
it has not been changed inside of Vim, automatically read it again.
When the file has been deleted this is not done. |timestamp|
If this option has a local value, use this command to switch back to
using the global value: >
:set autoread<

Resources