How do I use qconf to change the values of reporting_params?
qconf -mconf Looks like what I want but that opens an editor which I would like to avoid doing.
qconf -sconf > File
modify the file however you prefer.
qconf -Mconf File
In general upper case -M... or -A... switches will work with a file while lower case (-m... -a... ) variants drop you in an editor.
You could also set the EDITOR environment variable to point to a script that modifies the file in the way you want and updates its modification time before calling qconf -mconf.
According to man qconf you can list configuration and dump to file:
qconf -sq short.q > short.q
Modify the file, then load config back:
qconf -Mq short.q
There are other ways to do this, as specified in man qconf.
Related
Basically, I know I can go through my control panel and modify the path variable. But, I'm wondering if there is a way to through batch programming have a temporary path included? That way it is only used during that batch file execution. I don't want to have people go in and modify their path variables just to use my batch file.
Just like any other environment variable, with SET:
SET PATH=%PATH%;c:\whatever\else
If you want to have a little safety check built in first, check to see if the new path exists first:
IF EXIST c:\whatever\else SET PATH=%PATH%;c:\whatever\else
If you want that to be local to that batch file, use setlocal:
setlocal
set PATH=...
set OTHERTHING=...
#REM Rest of your script
Read the docs carefully for setlocal/endlocal , and have a look at the other references on that site - Functions is pretty interesting too and the syntax is tricky.
The Syntax page should get you started with the basics.
There is an important detail:
set PATH="C:\linutils;C:\wingit\bin;%PATH%"
does not work, while
set PATH=C:\linutils;C:\wingit\bin;%PATH%
works. The difference is the quotes!
UPD also see the comment by venimus
That's right, but it doesn't change it permanently, but just for current command prompt.
If you wanna to change it permanently you have to use for example this:
setx ENV_VAR_NAME "DESIRED_PATH" /m
This will change it permanently and yes, you can overwrite it in another batch script.
I would like to track changes to one config file. The reason for this is that multiple users access it to solve different issues, but every now and then those fixes break something else. diff function in Zabbix shows that a file was changed, but I would like Zabbix to also track what changed. Is there a combination of triggers that would let me do that? Any help is greatly appreciated.
Do you store file checksum or contents in the item? In any case, there is no built-in way to do that, but you can implement it with a script.
If checksum, you will need a way to store the previous version, new version and run the diff command. The easiest would be a userparameter that would do a diff between a temporary copy of the file and the current copy, then copy the current file over the temporary copy. In this case, you would store diff results directly in an item and your trigger would check that the last value is not an empty string. See https://www.zabbix.com/documentation/3.0/manual/config/items/userparameters for more information on userparameters.
If you are storing file contents already, presumably you want to reuse them. This would be a bit more complicated, as you would have to kick off the script whenever a new value arrives - maybe a special trigger could kick off an action that would compare the last two values (probably using the API), then push the result in another item that has another trigger. Unless you have a good reason to do it this way, I'd opt for the first approach.
Make a copy off your file
file.txt.copy or something like that. Make this file only writable by zabbix.
Create an item and trigger on zabbix to check when the file was changed (using diff or checksum)
Create a action on zabbix to execute a script that will
1 - diff between file.txt and file.txt.copy and send this diference to your email
2 - Copy file.txt to file.txt.copy so you can do the diff next time the file change.
To reate a action with script.
Create a action on zabbix. Go to "operations" tab. Select "Remote Command" from option.
Choose custom script.
Put the script with the whole path and arg's.
Sample
/opt/script/my_script.sh
The user zabbix must have permission to ruin the script.
Zabbix docs
I want to reexecute some targets when the configuration changes.
Consider this example:
I have a configuration variable (that is either read from environment variables or a config.local file):
CONF:=...
Based on this variable CONF, I assemble a header file conf.hpp like this:
conf.hpp:
buildConfHeader $(CONF)
Now, of course, I want to rebuild this header if the configuration variable changes, because otherwise the header would not reflect the new configuration. But how can I track this with make? The configuration variable is not tied to a file, as it may be read from environment variables.
Is there any way to achieve this?
I have figured it out. Hopefully this will help anyone having the same problem:
I build a file name from the configuration itself, so if we have
CONF:=a b c d e
then I create a configuration identifier by replacing the spaces with underscores, i.e.,
null:=
space:= $(null) #
CONFID:= $(subst $(space),_,$(strip $(CONF))).conf
which will result in CONFID=a_b_c_d_e.conf
Now, I use this $(CONFID) as dependency for the conf.hpp target. In addition, I add a rule for $(CONFID) to delete old .conf files and create a new one:
$(CONFID):
rm -f *.conf #remove old .conf files, -f so no error when no .conf files are found
touch $(CONFID) #create a new file with the right name
conf.hpp: $(CONFID)
buildConfHeader $(CONF)
Now everything works fine. The file with name $(CONFID) tracks the configuration used to build the current conf.hpp. If the configuration changes, then $(CONFID) will point to a non-existant .conf file. Thus, the first rule will be executed, the old conf will be deleted and a new one will be created. The header will be updated. Exactly what I want :)
There is no way for make to know what to rebuild if the configuration changed via a macro or environment variable.
You can, however, use a target that simply updates the timestamp of conf.hpp, which will force it to always be rebuilt:
conf.hpp: confupdate
buildConfHeader $(CONF)
confupdate:
#touch conf.hpp
However, as I said, conf.hpp will always be built, meaning any targets that depend upon it will need rebuilt as well. A much more friendly solution is to generate the makefile itself. CMake or the GNU Autotools are good for this, except you sacrifice a lot of control over the makefile. You could also use a build script that creates the makefile, but I'd advise against this since there exist tools that will allow you to build one much more easily.
For example I want to automate the adding of a SAMBA share by adding a share "block" /etc/samba/smb.conf (if it is not already present), as in: https://stackoverflow.com/a/16624958/227926
...rather than have to manually edit this file.
I'd want it to detect if the block was already present too.
thoughts?
Using Shell provisioner in the Vagrantfile may be the easiest way.
See: http://docs.vagrantup.com/v2/provisioning/shell.html
Use either inline (here document) or an external shell script in Vagrantfile, to check if the block exists (e.g. use grep/ack/ag etc and check the return value $?), if NOT, add it to the /etc/samba/smb.conf.
Hope it helps.
I am a newbie to Jenkins. Basically I want to increment a variable value each time after a job is executed. I created a global variable (Manage Jenkins-->Configure System) with some initial value. Now I want this variable value to be incremented each time after my job is executed.
How to go about this? Thanks in advance for any help.
You could keep the current value in a file, and put the file somewhere outside the workspace.
This way you can read it every time you want to, just by checking the file. When you need to update the number, just create a new file, with the value.
Unfortunately, every build creates a new session, so unless you have a global variable defined in the shell itself (outside of Jenkins, like PATH, using (for example) the /etc/profile file) AND have the ability to update it on the fly, it seems very unlikely to work.
Maybe you should consider using $BUILD_NUMBER variable? It is incremented by one for each build.
Use a property value from a file as part of your build and configure a post build action that will check the file with the updated value back into your version control system..
Depending on what number you need you might also want to look at e.g. the maven build number plugin and such things.