Apologies my bad english.
Well, I accidentally replace named.conf ..
is there any way to see the configuration again ...
named continues running without restart
show me something like configurations running ....
Thanks to all
PS. i tried to recover the file but it was not erased.
Unless you have a backup of some kind you're going to be out of luck. Although you might get some vague details from rndc you'll never recover the actual file...
You may grep your disk for it.
I usually add the same comment to all the configuration files i touch. Something like
## (pablo) /etc/inputrc
...
## eof
If i delete /etc/inputrc i can grep for it with:
fgrep -a -A 50 '## (pablo) /etc/inputrc' /dev/sda >/some/file/outside/dev/sda
You may use the same technique looking for something you know is in the file, like some domain name you were serving.
-a force text search
-A 50 display 50 lines after the pattern matched
-B 50 display 50 lines before the pattern matched
-B is usefull if you don't know exactly where the pattern will match.
Related
So I did an OS version-up in a linux server, and was seeing if any setting has been changed.
And when I typed "sysctl -a | grep "net.ipv4.ip_forward"
The following line was added,
net.ipv4.ip_forward_use_pmtu = 0
I know that this is because this parameter is in /proc/sys.
But I think if the result of sysctl before upload did not show this line, it was not in /proc/sys before as well, right ?
I know that 0 means " this setting is not applied...So basically it does not do anything.
But why this line is added.
The question is
Is there any possible reason that can add this line?
Thank you, ahead.
Even the question itself "added in the result of sysctl in linux server" is wrong here.
sysctl in the way you invoked it, lists all the entries.
grep which you used to filter those entries "selects" matching texts, if you'd run grep foo against the list:
foo
foobar
both items would be matched. That's exactly what you see but the only difference is instead of "foo" you have "net.ipv4.ip_forward".
Using --color shows that clearly:
Pay attention to the use of fgrep instead of grep because people tend to forget that grep interprets some characters as regular expressions, and the dot . means any character, which might also lead to unexpected matches.
I'm trying to display the output of an AWS lambda that is being captured in a temporary text file, and I want to remove that file as I display its contents. Right now I'm doing:
... && cat output.json && rm output.json
Is there a clever way to combine those last two commands into one command? My goal is to make the full combined command string as short as possible.
For cases where
it is possible to control the name of the temporary text file.
If file is not used by other code
Possible to pass "/dev/stdout" as the.name of the output
Regarding portability: see stack exchange how portable ... /dev/stdout
POSIX 7 says they are extensions.
Base Definitions,
Section 2.1.1 Requirements:
The system may provide non-standard extensions. These are features not required by POSIX.1-2008 and may include, but are not limited to:
[...]
• Additional character special files with special properties (for example, /dev/stdin, /dev/stdout, and /dev/stderr)
Using the mandatory supported /dev/tty will force output into “current” terminal, making it impossible to pipe the output of the whole command into different program (or log file), or to use the program when there is no connected terminals (cron job, or other automation tools)
No, you cannot easily remove the lines of a file while displaying them. It would be highly inefficient as it would require removing characters from the beginning of a file each time you read a line. Current filesystems are pretty good at truncating lines at the end of a file, but not at the beginning.
A simple but extremely slow method would look like this:
while [ -s output.json ]
do
head -1 output.json
sed -i 1d output.json
done
While this algorithm is plain and simple, you should know that each time you remove the first line with sed -i 1d it will copy the whole content of the file but the first line into a temporary file, resulting in approximately 0.5*n² lines written in total (where n is the number of lines in your file).
In theory you could avoid this by do something like that:
while [ -s output.json ]
do
line=$(head -1 output.json)
printf -- '%s\n' "$line"
fallocate -c -o 0 -l $((${#len}+1)) output.json
done
But this does not account for variable newline characters (namely DOS-formatted newlines) and fallocate does not always work on xfs, among other issues.
Since you are trying to consume a file alongside its creation without leaving a trace of its existence on disk, you are essentially asking for a pipe functionality. In my opinion you should look into how your output.json file is produced and hopefully you can pipe it to a script of your own.
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
This is something really bizarre. We have a Shell script, that is to do server configuration on every Linux box. and it contains this line of command:
#!/bin/bash
...
hostname=`hostname -f 2>/dev/null`
Most of time, this line of script returns back the correct host name value, as:
+ hostname=xyz.companyname.com
But I have seen couple of times, the whole configure fails, because it gives back such output:
+ hostname=xyz.companyname.COM
I don't know why the last piece of domain name becomes UP-Case value.
I don't see anything suspicious in the /etc/hosts file. Any idea what could make such happen ?
Thanks,
Jack
Check /etc/hosts.
My understanding is that hostname -f can retrieve the hostname from DHCP (?) or /etc/hosts—based on what condition(s), I don't know.
But you may have a
123.45.67.89 xyz.companyname.com xyz.companyname.COM
or something similar in there.
ssh root#$IP sed -i -e 's/listen\t80\default_server;/test/' /etc/nginx/conf.d/default.conf is there something I am not doing correctly?
I am doing to learn how to use sed - but I think the greatest route for making a general configuration across multiple server is to upload the conf file? Any input would be appreciated, thanks!
It appears that you are missing a tab:
listen\t80\tdefault_server
If it was me, I'd replace the tab pattern with general whitespace pattern to allow a little flexibility:
listen\s\+80\s\+default_server
or
listen[[:space:]]\+80[[:space:]]\+default_server