I'm building a flask application and use dotenv file to switch some variables up to environment, such as production, development, and testing.
AFAIK dotenv is mainly used for security purpose, so should I delete dotenv file from the server once I started to run the application?
If so, when the application is down I would need to pull the dotenv from somewhere, re-run the application, and then delete the file again.
It's not likely to be a good idea to leave dotenv file in the server,
but the above sounds a little bit annoying from an operation perspective.
What is the best practice?
The correct way to protect this file is with UNIX file perms.
chmod 600 .env
Then check the perms look correct with ls -l .env:
-rw------- 1 appuser somegroup 0 Oct 18 01:23 .env
Anyone who has shell access with this user account, could read the file, but could also use the set command to view all environment variables. Taking the above step prevents other system users from reading the file.
The security aspect of dotenv is that it prevents you hard-coding secrets into your .py files which would result in them being committed to source control.
Related
I have a freeradius server setup with google authenticator to provide a basic working multi-factor setup.
Everything works when I run radiusd in debug mode as root. If I start it as a service, logons fail and this messages is recorded when processing messages:
radiusd(pam_google_authenticator)[1115]: Failed to read "/home/user#domain.com/.google_authenticator" for "user#domain.com"
I think this must be a permissions issue since it works fine when run as root.
I don't really want to edit the permissions on each secret file for every user.
I have tried specifying root in
/etc/raddb/radiusd.conf
user = root group = root
but still the service fails unless run from the command line as root. Does anyone have a nice elegant solution to this conundrum?
I think you should check out your systemd service file for radiusd. It might look something like:
https://github.com/ipfire/ipfire-3.x/blob/master/freeradius/systemd/freeradius.service
You can add User= and Group= in the [Service] section of the .service file if needed. See
https://unix.stackexchange.com/questions/347358/how-to-change-service-user-in-centos-7
and
https://serverfault.com/questions/806617/configuring-systemd-service-to-run-with-root-access
It would be a good idea to put the contents of the .service file for radiusd in your post.
In Nodejs, when running
fs.readdirSync('/tmp');
I get result like:
['launchd-493.Je0U5v','npm-898-26dc6432']
Where is this /tmp folder? what does its path look like? (I'm using OSX)
The reason I'm asking this question is because I'm build a node app on a web host which has a read-only-files system in the node app folder, and I need to save some tmp files which is then uploaded to a backend like Parse.
Thanks!
Most servers should use the system temp folder; /tmp on OS X aliases to /private/tmp, which has the default permissions: lrwxr-xr-x# 1 root wheel.
Unless your server is abnormally locked down, you should be able to use it.
You may want to consider something like tmp as well which is tailored for temporary storage.
I have following code that works fine on my localhost running node.js 0.12.0. The code creates a new file, and copy data from readable, but it doesn't create new file on Heroku.
var output = fs.createWriteStream('public/images/test/testfile.png');
readable.pipe(output);
I thought it has something to do with the permission, but whenever I change the permission on the folder using heroku run bash and then chmod -R 777 images/ Heroku resets it back to its original permission which is drwx------.
So may be the problem is something else?
Please note that it fails silently, no exception, nothing in the log.
In Heroku a dyno's local file storage is not persistent (besides the git repo files obviously), so if you write a local file and the dyno restarts the file will be gone, and if you start another dyno it won't be able to "see" the file.
heroku run bash starts a new "one-off" dyno (can read about it here: https://devcenter.heroku.com/articles/one-off-dynos), so the file will not be accessible that way.
If you want your data to persist, better use some database or persistent storage addon.
I can't add /usr/local/bin to the apache users PATH variable. The user doesn't have a .profile, I can't su to the user, I can't export to the PATH from php using exec and adding
SetEnv PATH /usr/local/bin
To either the http.conf or the .htaccess file doesn't make a difference. I can't find the envvars file to change that but I suspect there's some other problem.
I have restarted apache, and indeed my server.
Ended up following what Alfe suggested in his answer, except rather than in the /etc/init.d/httpd file (which could be overwritten easily on update) I added to /etc/sysconfig/httpd:
export PATH=${PATH:+$PATH:}/usr/local/bin
Have a look at the /etc/passwd to see which login shell the apache user has (on EC2 Ubuntu instances it should be /bin/sh which is a link to /bin/dash). Then have a look at the man page of that shell and find out which configuration files are read upon login. (For /bin/dash that would be .login in the user's home directory.) In those you should be able to extend your $PATH as you like.
EDIT:
Since you seem to have no login shell for that user: Have a look at the /etc/init.d/* scripts which start the system services. Apache will be one of them. They are started as root and may change the current user (e. g. to the apache user). In there you might be able to adjust the PATH as you like it.
Patching those scripts, however, is not considered typical configuration. Updates might overwrite what ever you patch there.
I see several db.* files in my /home directory, and it seems they come from perforce. For example, some files are db.archmap, db.bodtext, db.change, db.changex
Are these files useful? Can I delete them? They are making my /home directory messy
You have started a server using your home directory as the Perforce server's P4ROOT folder. Those files are files that are generated from starting the server and cannot be deleted unless you want to hose your server installation. It's not clear to me how you've started the server instance, so I'll try and cover multiple bases with my answer.
If you want to start up the server under your own account, you should set the P4ROOT environment variable and point it to where you want the server to store its files. Alternatively, when you start the server, you can specify the root folder on the command line using the -r option:
p4d -r /home/mark/p4server
which would put the server's files into the directory called 'p4server' off of my home directory.
Typically it is best to run the perforce server using a user that is dedicated to running perforce. I use a user called 'perforce'. I set P4ROOT (and other variables) in that users environment. If you cannot use a separate user, it might be easier to use the -r command line option that I mentioned above.
Those files are only server files, not client files. So it is safe to delete them, but if you start the server back up it will recreate them. So you might want to uninstall the server.
Unless you are running a beta version, they have p4sandbox coming soon(maybe in the beta, I forget) which MAY create those files. I don't have a beta version, so I can't verify what new files the client may or may not create.
You can check the documentation here to see what these files do/are for.