As stated in the documentation, VOLUME instruction inherits the directory content and permissions existing in the container, so you can workaround the problem with a dockerfile like this:
RUN useradd -d /home/ubuntu -ms /bin/bash -g root -G sudo -p ubuntu ubuntu
RUN mkdir /opt/myvolume && chown ubuntu /opt/myvolume
There is currently no ability to restrict jobs which are able to run on the same agent from potentially interacting with each other. There are a bunch of feature requests asking for this sort of granularity, but if I understand your question correctly the most fitting request would be this one BAM-2504 Jira Ticket
It's a huge gap in the product line, the ...
Thanks to the people here, the solution is quite simple (but not obvious):
My GNU/Linux container host has SELinux activated, and that's why I was having permissions problems. The solution is to simply append a :z to the podman run volume argument so that this:
podman run -it -v /host/foobar:/src_dir /bin/bash
podman run -it -v /host/foobar:...
If your question is how to manage database changes consider something like Flyway. This lets you control your changes via tracked config files in your repository and apply them via an automated & controlled process - use your normal code review & promotion steps.
If the question is "how do I get devs to stop bugging me to run arbitrary SQL commands" ...
You could embed database schema and data changes into source code control by using a concept called database migrations. These can then be executed on dev and staging environments as part of a partially automated deployment process.
For example in my environment (PHP Web application), I am using Doctrine Schema for schema updates, Yii2 migrations for data ...
I had a similar problem, this worked for me:
Write Docker file with:
# Create app layer:
# Create app user & group "testuser" with IDs:
RUN groupadd -r testuser --gid 1234 && useradd -d /home/testuser -ms /bin/bash -r -g testuser testuser --uid 1234
# Create "testuser" working dir:
# Make working dir known ...
I see a first problem, DevOps is about building teams able to handle an application from build to exploitation.
So your devs should have access to the databases, you quoted various cases which are the reality for a lot of people and the major drawback which is turning you and your colleague in a bottleneck as well as impeding your own work.
Other answers ...
The reason for the failure is that the server in question, unlike all the others, had sftp disabled.
Why the error messages are what they are, I don't know (why the errant scp transfer mechanism failed?), but I don't have time right now to investigate with the debug option enabled.
But that was the issue, and adding scp_if_ssh=True to the [ssh_connection] ...
There are 4 type of user permissions in Jenkins:
Jenkins is accessible for everyone with no permissions. Basically anyone can do anything. This should be used for internal use only.
User authentication (all admins)
All users are admins. The authentication method can use Jenkins’ own user database, LDAP, Unix user/group database, servelet container (e....
As described in https://github.com/docker-library/tomcat/issues/35, this is related to the storage driver used (aufs). Changing to use overlay2 solved the issue:
docker run -ti --rm \
-v $PWD:/workdir \
-v $HOME/.ssh:/root/.ssh \
--user $(id -u):$(id -g) \
As long as you're not doing anything funny with the entrypoint in the container, this will leave files owned as the user that invoked Docker.
What you need here are the az ad app permission commands.
Here is a complete example (assuming powershell):
$apiId = "00000002-0000-0000-c000-000000000000" # Windows Azure Active Directory
$apiPermissionsId = "78c8a3c8-a07e-4b9e-af1b-b5ccab50a175" # Directory.ReadWrite.All
$spn = az ad sp create-for-rbac --role="Owner" --name blah | ConvertFrom-Json
We keep a RO clone of the important DB's. Any dev can access the basic RO clone if he's in the right dev group vpn, because the cloudsql instances are deployed in a private service net that peers with our private net and get be gotten to from the outside. If not they can get added it a group.. Then they just need the ip address and they need the user and ...
Ideally dont run docker as superuser(root). You should create a user within dockerfile and chown the file system with that user. You can create a user and then add access to that user on the file system. In the below example there is appuser , with ownership to src
RUN useradd -r -u 1001 -g appuser appuser
RUN chown -R appuser.appuser /src
In your Dockerfile:
RUN usermod -u $UID node && groupmod -g $GID node
Then using docker build:
docker build --build-arg UID=$(id -u) --build-arg GID=$(id -g) .
The ARG lines provide defaults. If you leave off the --build-arg flags, they will be used. If you do use the --build-arg flags values those will be used instead.
Can't comment yet, but most extensions host their source code publicly. So you could read the source code to check if something is going on that you don't want.
If the source code is not available, you could check the company for certain certifications like ISO 27001 or the like so you know they get audited.
There is a balancing act here between the simplicity and maintainability of your solution, and how auditable creating separate service principals or users for each of your external customers. I suspect only you can actually decide which is the best practice in your specific legal and regulatory situation.
On the side of having a single Service Principal ...
I usually stick to a 755 (or rwxr-xr-x) on my web root, but I do not think this is the issue you're running into since your directory is already set to that. nginx should have access to your directory. The question then becomes the permissions (or existence of) the file you're trying to access. The files within your directory will need to be readable by ...
According to the Nginx docs you can configure the user which runs Nginx. By default the user is nobody.
You can read this Ask Ubuntu question that explains how to configure Apache2 to run as a different user. The default user running Apache2 is www-data.
A common strategy, and one I think may work for your goal, is to assign the users that need to deploy ...
... me and another coworker ... are the only people who have access to the production database.
That's a good starting position.
All too often, DBA's find themselves trying to close the stable door after the horse has run off.
So when any other developers need to execute a MySQL query on the production database ...
Why are Developers running ...