I have an installed and configured squirrelmail in my linux server which i used to send and receive emails.
Now i have to format the linux server... then before formatting how can i backup my emails and configuration so that they can be used again ?
Backing up your email messages is not a SquirrelMail issue. SquirrelMail is an IMAP client and does not store email itself. You need to determine what kind of storage is used for your particular email system. If it's a very simple/default *nix email setup, you might start by looking in /home/ for a directory with a name indicative of the purpose, such as "Mail", "Maildir" or similar. You might also look in /var/mail or /var/spool/mail
There is some starter information on some ways to migrate email between servers here: http://squirrelmail.org/docs/admin/admin-11.html#ss11.2
Also, you might want to re-think why you need to format the whole system. *nix systems don't need to be treated like Windows systems do. They can usually be rearranged, expanded, tweaked and otherwise changed without the need for reformatting.
As for SquirrelMail itself, there are a couple things you may want to back up, which would be any configuration files for SquirrelMail itself (in its "config" directory) and any plugins you'd installed (you can usually just copy the entire plugin directory for most typical plugins and transport them to the new system with minimal hassle), any custom themes you may have had in the "themes" directory, and finally, all user preferences. The location of your user preferences depends on your configuration - might be in a database or might be wherever the "$data_dir" setting points to (find this by looking in "config/config.php" or by using SquirrelMail's configuration tool ("config/conf.pl"). If you have user preferences stored in a directory, you can normally just copy the whole directory. Note that even if you have SquirrelMail configured to keep user preferences in a database, some plugins will still use the data directory setting for some purposes, so it's advisable to back up that directory no matter what.
The wiki page at SquirrelMail detailing upgrades is the same thing you need: http://squirrelmail.org/docs/admin/admin-4.html
When backing up and migrating things like this between servers, you need to be very careful about file/directory ownership/permissions on both your email data and your application configuration and preferences data. If user and system account names and UIDs are not the same between the servers, you'll want to be very careful that you adjust the ownership of the files to suit the destination server.
Related
I've started working on an Azure project. In terms of config, I currently have three files: ServiceConfiguration.Cloud.cscfg, ServiceConfiguration.Local.cscfg and ServiceDefinition.csdef.
ServiceDefinition.csdef is the template file for the csfg files. ServiceConfiguration.Cloud.cscfg contains all the actual Azure configuration, including DB passwords, SAS keys etc.
Should ServiceConfiguration.Cloud.cscfg be checked into source control? I wouldn't have thought so but a quick search on github for the file shows that it is.
If it should be checked in, how should the sensitive password data be managed?
I typically check in the configurations. The reason is that the behavior of your application will change dramatically depending on these configurations. For example -> number of roles for a distributed application directly affects how you process incoming messages and the vmsize directly affects how much memory you have. You may encounter issues debugging problems if each developer is using a different configuration. This standardizes your deployment.
Anything with plain-text password information shouldn't be checked into a public repo unless you want people to have access to that information.
You can add this file to the .gitignore file and prevent it from being checked in.
Provide a different ServiceConfiguration.Cloud.cscfg named something like ServiceConfiguration.Cloud.cscfg.template with all the config info of your cloud service minus the password values. If someone forks your project they need to use that and fill in the appropriate values and rename the file.
Do this and change all your passwords to something else. Even if you delete this file from the repo, it still exists in the history and anyone can view it.
I'll try to keep this question short, but it is in 2 parts, please:
Where should config files for nodejs/npm CLI tools be saved?
What should they be called?
Let's say I write a node.js CLI tool that, for example, grabs today's weather and displays it in terminal. I call it weather-getter. Note, the main goal is not to be called programmatically, but typed into terminal like BASH. It is intended to be run by typing its simple name after installing globally, or via a directory in the user's local /bin. (Sudo is not required for its install.)
This project would be installed normally via npm. It can receive a zipcode via an argument like:
gavin#localhost:~$ weather-getter -z "12345"
OK the program works fine like this. My next step would be to allow the user to save a config file somewhere, and pull from that config file for defaults. Similar to a .vimrc file. This config might look like this:
{
"zipcode": "12345",
"language": "en",
"unit": "fahrenheit"
}
I suppose it should begin with a dot. I also suppose it should be located in the npm module install, and not in ~/. Or should I consider using ~/ or /etc/ or ~/.config or ~/.local like many other programs? Should node programs try to use a common directory, such as ~/.config/node/ or ~/.config/npm/? And if the file is in there, should it begin without the dot?
Note: My question is not about reading/writing a file with node.js, just recommendations on the config location and naming convention. Thank you!
Since this is a generic CLI application (which only so happens to be implemented in Node.js) installed into the system path, you should follow the best practices or rules established for the target operating system.
Unix/Linux/OS X, similar
In order of priority, these would be (but are not limited to):
~ (User's home folder) - many programs store user-level config in their home directory, usually in a dot-prefixed file, followed by the application's name (or similar) - i.e. ~/.weather-getter
/usr/local/etc, /etc - system-level configuration files. These should generally apply to all users in the system and thus should take less precedence than settings in home folder. The difference between these two etc paths is usually that the former is used for user-installed programs, whereas the latter is for system-level programs (this is especially true for Mac users using Homebrew). This distinction is, however, not always respected and therefore both locations should be checked for config files (preferrably with the /etc directory having lesser priority).
Your application's root - these should be the default settings for your application, a fallback when no user or system config has been found.
Other locations may be considered if needed.
Windows
This is usually somewhere within %APPDATA% directory if your app allows GUI or at least CLI configuration management, or the Windows registry (using winreg, for example). I have personally little experience with Windows development/CLI so I welcome any further comments or answers on this topic. I believe using the user's homefolder would also be acceptable as long as the file can be marked as hidden (so it does not clutter the view).
Some general considerations
Many CLI applications install their default configurations into one of the mentioned locations so the user has a good starting point when configuring your app
The way your configuration options are treated when multiple configuration files are present (are they merged in some order? Is only one used? Which one takes precedence?) is completely up to you, but you should make it clear in your documentation, perhaps even mention it in the configuration files themselves
If your application requires multiple configuration files it is preferred that they are grouped in their own folder
Update about dotfiles
The reason why some files or folders are prefixed with a dot is to hide them from users' normal view (i.e. when browsing their home directory via a GUI). It is therefore common practice to use dot-prefixed file/folder names when storing configuration files in directories where users normally operate, but not do so when storing config files in system-level folders.
The ospath package has a function data() which returns a sensible location for such files for each of the major platforms.
We created an OpenGrok server and indexed our sources. The problem is that the SCM we use (here, Perforce, but I guess this does not apply to Perforce only as permission at file/folder level is widely used) restrains access per file or folder, and OpenGrok doesn't !
So today, any user performing a search with OpenGrok will retrieve all files, even the ones for which he/she should not have access to ! Which is, in my opinion, a blocker: we will never release such a security breach in production.
Do you know any setup/workaround to implement such a security ?
EDIT : this OpenGrok should be used by anyone, I could of course retrieve Perforce sources with my permissions (so I would only get the files I have permissions for) to perform searches but this would not answer this requirement of widespread audience.
https://github.com/OpenGrok/OpenGrok/issues/503
feel free to join debate there(or in similar requests), ev. send patches
Did you consider creating a different p4 user for just syncing your source code for OpenGrok indexing? That user can have limited access based on the entries in protections table of P4. That way you can sync the code at folder level while hiding the sub folders based on protections table permissions.
I have done a similar setup for my opengrok instance :)
Well, I finally found a workaround:
locate your tomcat server XML config file (mine is located in .../apache-tomcat-8.0.52/conf/server.xml)
add the following markup in Server > Service > Engine > Host:
< Valve allow="< list of IPs allowed>" className="org.apache.catalina.valves.RemoteAddrValve" deny="" />
I have a daily script that generates this list of IPs from the workstations allowed and updates this file accordingly. This list is like "1.2.3.4|5.6.7.8|6.2.5.3".
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.
For example some parts of the client spec map files from a 'Published' depot. Is there a way for these so-called published maps to be forced read-only, i.e. they cannot be opened for edit?
For example (ignoring [not editable]):
//Development/foo/... //client/foo/...
//Published/bar/1.0/... //client/bar/... [not editable]
//Published/qux/2.0/... //client/qux/... [not editable]
In other words I want to prevent files from being opened (say, being locked by default) and am wondering if this can be enforced at the client spec level.
If not, is there a way available without making the 'Published' depot read-only to certain users?
The only way to do this properly is via the Perforce permissions table. You get to this either with p4 protect command or via the Admin menu in P4V.
Just open it up - you need admin rights - and add a line to the table to mark those files as read only. That will allow your clients to sync to the files but not be allowed to open for edit (or delete etc).
You have ultimate control in the permissions table. You could also refine this to allow just a subset of users to be able to modify the file, while everyone else sees it as read only.
The Perforce admin guide is pretty good on the permissions table. Direct link here.
you can use p4 lock, which prohibits others from submitting changes.
you can also manage user access, see p4 protect and p4 group. i believe this can be used on a file by file basis.
You could create a dummy client and lock those files on the dummy client. Then, just don't let anyone use that client, e.g. by putting it on a server.