I've been playing with NixOs and was wondering how one can modify a config file.
For example I tried to modify the ssh configuration file /etc/ssh/ssh_config (to allow root ) but
I can't save the file, as it's only a link.
I understand that modifying a file manually is not the way to do (because the system needs
be aware of the modification), so what is the NixOs way to do it ?
See programs.ssh options.
Also note there's an extraConfig for further text in ssh_config.
Related
I started to learn Linux not long ago and have read some instructions about systemd and journald.
My question is: Is systemctl edit systemd-journald a proper way to configure systemd-journald.service?
According to the man page of journald.conf.d, we can put configuration files in these directories:
/etc/systemd/journald.conf
/etc/systemd/journald.conf.d/*.conf
/run/systemd/journald.conf.d/*.conf
/usr/lib/systemd/journald.conf.d/*.conf
/usr/local/lib/systemd/*.conf.d/
I also noticed that systemctl edit systemd-journald would create /etc/systemd/system/systemd-journald.service.d/override.conf to override the defaults for systemd-journald.service which is not mentioned in the man page above.
Is it a proper way to configure systemd-journald.service?
What are the differences between all these directories?
Is systemctl edit systemd-journald a proper way to configure systemd-journald.service?
No. This command allows to change the service definition, not the service configuration.
The service definition contains information that systemd requires to run a service, and not the configuration of the service. The default service definition file is usually located in a lib directory, e.g. /usr/lib/systemd/system/systemd-journald.service. The command systemctl edit systemd-journald allows to override values from this definition. It will create a file /etc/systemd/system/systemd-journald.service.d/override.conf that contains only values that differ from the service definition.
The preferred way to edit the journald configuration is to create a file with the suffix .conf in the directory /etc/systemd/journald.conf.d, e.g. /etc/systemd/journald.conf.d/50-local.conf. This file may contain your configuration. For example, to make your journal persistent, the file should contain:
[Journal]
Storage=persistent
An alternative would be to edit the file /etc/systemd/journald.conf. But this solution has one drawback: whenever a systemd update brings a new default configuration file, you're asked to merge your changes with the new default config.
Files within /usr/lib and /usr/local/lib are usually the place for files from your linux distribution and not for user configuration. Files within /run contain working data for running processes and not persistent configurations.
Further details may be found in the man page of journald.conf.
I'm trying to use a software library to run some computations. These computations can be customized using a few configuration files in its share directory. Unfortunately this library only provides hard coded paths to specific files in its (read-only) share directory which store these default configurations. Thus right now only a super-user or administrator could modify them. The library doesn't search for any user-local versions of these configuration files. I'd like to develop a wrapper tool which additionally takes a path to an alternate version of one of these configuration files in the users home directory and have that file somehow appear to "mask" the original file on the file system for the duration of process execution without actually modifying the original file in any way (since it can't). Is there a Linux tool I could use to do this sort of thing?
I'm configuring Apache and the setup documentation has me creating a file in .etc.apache2/sites-availible named after my site (example.com) but doesn't say what type of file this is. I tried to just write it up in TextEdit, but then it saves it as example.com.txt. There is already a default there, but it doesn't seem to have a file type. So how can I may a similar file type to put the virtual host code in?
The extension of the file would not matter. In fact, you can just edit the default file that is already there.
Apache Documentation just recommends you to create a separate file for your domain, sine it is cleaner and easier to maintain.
Once you create that file, and add all the corresponding e.g. vhost configuration, you can run:
sudo a2ensite your_file_name
to tell apache to use your file from now on.
The filetype:
.conf
Put in it all the VirtualHost directives for your domain...
The majority of our C# projects configuration is kept in *.ini files. Mainly these files hold
many sections affecting all aspects of programs behaviour. But besides of regular configuration data some of sections are vulnerable like db connection string or server password. We try to keep this sections in following forms:
[Database]
user=testuser
database=testdb
password=
But when developer is testing application he must fill the config in order to start application. It is quite common that some of the passwords are commited into version control.
Because these files are indispensable for application they cannot be included in .svnignore.
Probably what I'm looking for is some kind of script (maybe in powershell). That would scan all *.ini files and erase all passwords. The most interesting solution would be adding some external password storage that can be used both to encode and decode passwords in *.ini files.
I always push to store configuration template files in subversion, but not actual configuration files. So if the configuration file is "config.ini" then I'll check in a "config.ini.template" populated with non-working sample data.
Then to prevent multiple developers from checking in their individual "config.ini" files, I'll add the actual configation file name to the svn:ignore properties list.
This forces the developer to copy the file and modify it appropriately for their environment, but eases the work of that task by not forcing them to find out which fields need to be present. If you have the time, you can even embed comments into the template file to simplify the meanings of some of the configuration options.
At the top of the file, include the directions of how to configure the system using the template, which should read something like:
# *** CONFIGURATION TEMPLATE --- DO NOT MODIFY THIS FILE ***
# 1. Make a copy of this file in the same directory with the command "copy config.ini.template config.ini"
# 2. Edit the new copy and follow the rest of the instructions
#
# Change "this.system.hostname" to the hostname of this system
Hostname = this.system.hostname
# Set the answer "23" to "42"
Answer = 23
You get the idea....
If you have problems (or think you might have problems) with people checking in their configuration options over the config.ini.template file, then I'd recommend using "svn lock" on the template file. However, with the appropriate warning, I've never found it necessary.
I'll not answer your question and instead recommend a different approach, assuming it's not too late to change the relevant design.
You should not store passwords in the same files as the rest. Have the application read a dedicated password file (or retrieve the password from a password storage service) in addition to the regular configuration file. This is not just about not storing passwords in svn, but also about not having passwords exposed to shoulder surfing, accidentally mailed or posted when someone asks for help with a non-working configuration, etc.
I am looking at the cruisecontrol web dashboard. I can see one farm and one server. However, I don't see any way to add a project?
Is this something I can do with the UI or do I need to edit the config file by hand?
You'll need to edit the ccnet.config file by hand (located within the CruiseControl directory) to add projects. There are some graphical tools to help you do this however you do get used to doing it by hand fairly quickly - just have the documentation near by!
Update: An example of one such tool is http://www.codeplex.com/ccnetconfig
You can use CCNETConfig to edit the config file through an UI although it doesn't support higher version > CruiseControl.NET 1.4.
You have to basically edit the configuration file by hand, however I have it setup so that the raw config file is split into different include files, each of which is setup in my source control system. Then I created a project for the configuration, and then for the whole config. So when something changes in the config, CC.NET itself pulls out the changes, recreates it's config files and the refreshes the system configuration.
This means that anyone can edit the config (if they can access the files in sourcecontrol), and no-one has to go into the program files directory of the CC.NET machine itself.
Not sure whether this answers the question you asked, but this is how our setup works