Looking at this Dockerfile it stars with:
FROM sequenceiq/pam:centos-6.5
MAINTAINER SequenceIQ
USER root
Now that seems redundant, since by default you'd already be root. But for argument's sake - let's look at the parent Dockerfile....that doesn't change the user.
Now let's look at the grandparent Dockerfile. (It doesn't seem to be available).
My question is: Is it redundant in a Dockfile to run USER root since you're already root?
Yes, it's redundant, but there's almost no downside to leaving this redundancy in. This may have been done to develop against other images, or to support uses that may swap out the base image. It could be done to prevent future issues if the upstream image changes it's behavior. Or they may just want to be explicit so it's clear this container needs to run commands as root.
If an image was generated from a source that changed root to a user, you may not have access to all resources inside it. However, if you load the image:
FROM xxxxxx/xxxxxx:latest
USER root
That will give you root access to the images resources. I just used that after being refused access to change /etc/apt/sources.list in an existing image that was not mine. It worked fine and let me change the sources.list
if you are already root, then it's redundant to use it.
As #BMitch also points out, you can use USER root to ensure you are not going to break things if the parent image changes the user in upcoming versions, among other things.
It actually depends on the image. In some images, such as grafana/grafana, the default user is not root and there is no sudo. Thus you must use USER root for any privileged task (e.g., updating and installing apps via apt).
Related
A while back I created an instance of mariadb inside a docker container on a machine running Ubuntu. I've since learned that I'll need to update some settings to keep things running smoothly, but when I created the image, I did not specify any .cnf volumes. How do I update/create a .cnf file for this image? I'm a complete newb when it comes to docker, so please spoon-feed me.
I've tried accessing the file from within the image, but there are no text editors.
The defaults of MariaDB work pretty much out of the box (container) for small instances. You should only need to change setting when problems occur.
If you have spare memory you can increase your innodb_buffer_pool_size.
With the mariadb container, you don't need to edit the .cnf files, you can just add a few options on the command line per the docs (that you should defiantly read).
Recommend using the defaults for a while, and if you encounter problems, include a new question on dba.stackexchange.com that includes show global status output and specifics on the queries that are slow (show create table TBLNAME / explain QUERY).
I'm wondering if there is a method to define, and launch, a group of services configured in a docker-compose.yml file.
To make a real world example, I'm working with laradock: it has a lot of services configured (I think more than 50) - You have to "select" which one to run every time.
In fact to run a normal php + apache + mysql stack, you can use:
docker compose up workspace apache2 mysql
The final question is: can those three services be grouped under an alias, like "amp" and this alias used to launch these services with:
docker compose up amp ?
What I have tried, already
I thought about duplicating the docker-compose.yml into a simpler one, where only the required services are present.
Anyway this configuration I'm using (laradock) it's quite complex, being able to define an alias, would lead to a much easier to handle configuration.
Imagine the case where you need to add one more service to the group: instead of doing cut & paste of it's configuration(s), you just add it's name, and nothing else.
Is this possibile somehow?
Thank you
One simple way that might do what you want is to create an alias for your shell/terminal. To do that in a "permanent" way you might need to edit the ~/.bashrc or ~/.bash_profile files. For reference you can check, for example, this link here.
That way if you want to change the services of a "group" (which will be defined by the alias), you will just need to edit the line for that alias in the file.
I recently began looking into WebDAV, as I found it to be an option for letting me play a Blu-ray folder remotely - i.e. without requiring the viewer to download the whole 24gb ISO first.
Add a WebDAV source in Kodi v18 to a Blu-ray folder - and it actually plays! Very awesome.
The server can also be mounted on Windows with
net use m: http://example.com/webdavfolder/
or in Linux with
sudo mount -t davfs http://example.com/webdavfolder/ /mnt/mywebdav
-and should then (in theory) play with any software media players that supports Blu-ray Disc Java (BD-J), such as PowerDVD and VLC.
vlc bluray:///mnt/mywebdav --bluray-menu
PowerDVD.exe AUTOPLAY BD m:
(Unless of course time-out values has been set too low, which seems to be the case for VLC at the moment).
Anyway, all this is great, except I can't figure out how to make my WebDAV server read-only. Currently anyone can delete files as they wish, and that's of course not optimal.
So far I've only experimented with SabreDAV, because afaik that's the only option I have if I want to keep using my existing webhost. Trying with very minimal setups, because I've read that minimal setups should default to a read-only solution. It just doesn't seem to happen.
I initially used the setup from http://sabre.io/dav/gettingstarted/ and tried removing some lines. Also tried calling chmod 0444 MainFolder -R on the webserver. And I can see that everything does get a read-only attribute. But it changes nothing. It's still possible to delete whatever I want. :-(
What am I missing?
Maybe I'm using the wrong technology for what I want to do? Is there some other/better way of offering a Blu-ray folder for remote viewing? (One that includes the whole experience - i.e. full Java menus etc).
I should probably mention that all of this is of course perfectly legal. It is my own Blu-ray project - not copyright material.
Also: Difficult to decide if this belongs on StackOverflow or SuperUser. I ended up posting it on StackOverflow because SabreDAV is about coding, and because there's no sabredav tag on SuperUser.
You have two options:
Create your own file/directory classes for sabre/dav that simply throw an error when trying to delete. You can basically start with a copy of Sabre\DAV\FS\Directory and Sabre\DAV\FS\File and change the methods that do writing.
Since you're considering just using linux file permissions, really the key thing you are missing is that that 'deleting' is not controlled on the file or directory you're trying to delete. To delete a file or directory in unix, all you need is write permissions on the parent directory. However, I wouldn't recommend going this route as doing this will just cause a weird error in sabre/dav, which might leave clients in a confused state. It would result in a 500 error, not the expected 403 error.
So I have a web application running on Centos 6.5.
The application is a Ruby/Rails app, but the images are served by Apache HTTPD.
The application folder is in a user home folder, but I've granted HTTPD the correct permissions, and have enabled httpd_enable_home_dirs within SELinux. All static images are working just fine.
The problem I am seeing is when an end user uploads an image (A profile icon), the SELinux context for the file is getting set to unconfined_u:object_r:user_tmp_t:s0 instead of unconfined_u:object_r:usr_t:s0.
If I manually run restorcon on the file, the context gets fixed, and the image works. Any idea how I can make sure the file gets created with the correct context? I've looked into using restorcond, but it looks like it won't recursively check subdirectories, and the subdirectory structure is not predictable.
Any help is appreciated.
Most likely your application is moving 'mv' the object from /tmp, or /var/tmp to the destination location.
By default when a object is moved with 'mv', then so is its security metadata. Thus the object ends up at the destination with old and inaccurate security metadata. Running 'restorecon' on the destination objects resets the contexts to what the policy thinks it should be.
There are various ways you can deal with this. Either allow your webapp to read the object with the inaccurate context or tell your webapp to either use 'mv' with the -Z option, or use 'cp' instead. (the 'cp' command copies the object, and as a consequence the target object ends up with the appropriate security metadata, usually mostly inherited from the targets parent directory.
So apparently SELinux suppresses some error messages...
In order to debug this I had to run
semodule -DB
This rebuilds/restarts the local policy with the disable "don't log" flag. Once "don't log" is disabled, the error messages show up in the audit log and you can add a new policy using the regular:
sealert -a /var/log/audit.log
Then find the audit2allow command for the error in question.
You can set your logging back to normal after by running
semodule -B
I trying to put my Mac's data in order.
I have many rc-files at my root such as .vimrc, .srceenrc and .bashrc.
I would like to put these files to the specific folders such as .vimrc and .screenrc to ~/bin/coding and .bashrc then again to ~/bin/shells.
How can you determine where these rc-files must be?
Seriously, you should leave them where they are. Applications will be looking for them in specific locations (probably your $HOME directory which is not root, by the way, or shouldn't be). This is a very old UNIX convention that you should attempt to change only if you fully understand the consequences.
Not meaning to sound condescending but your error in naming your home directory as your root directory seems to indicate your knowledge level of how it all works is less than it should be to understand those consequences (apologies if that offends you, I agonized over the best way to say it - what I mean is that you should tread carefully).
If you move them, you will have to ensure you run the applications that use them with their paths fully specified, and some applications may not let you do that.
They all start with "." so that they're hidden to the normal ls commands and, if you're using a graphical file browser, there should be a way to hide them there as well (such as the Gnome File Manager CTRL-H).
Configuration of a program is both defined at system-level and user-level, you can tweak the user-level one, which resides in your home, to help you in what you need.
No need to group them in subfolders as you said: leaving them in your home (not root) is following the convention everybody uses, rc-files usually stay there after the program has been uninstalled, so if some day you make a fresh install you'll find the application configured as you left it.
Also, by leaving them in your home, you can bring your own home folder to another system and have the environment set as you like it.