Unhide a hidden Gerrit project - gerrit

We have a project in Gerrit that is hidden. I have two questions about this 'feature':
Where can I find this setting on disk or database so I can verify the state of a project?
How can I make a hidden project active again?
I'm admin in Gerrit and have CLI access to the server, so I can access files on the server if that is necessary.
Regards,
Johan-Kees

The probably easiest way is using the web UI. Access the project settings and change the State from Hidden to Active (you can access this page via https://review.example.com/#/admin/projects/example for project example):
You can also use the gerrit set-project SSH command to change a projects visibility (see docs):
$ ssh -p 29418 review.example.com gerrit set-project example --project-state ACTIVE
I guess this is saved in the project.config in the refs/meta/config, which would be another way.

Related

How can I include secrets to my docker image?

I've built myself a web api that uses a sql database. I've used Visual Studio to create this project, and have the ability to right click and "manage user secrets" on my project file.
Its in user secrets that I've stored my connection string and I dont want to add it to my github (private) repo.
The user secret is a json file.
How do I noe include these secrets? Do I include them in the project, making them a part of the image? Or do I do something fancy with the running instance?
There's many ways to go about doing this, but typically you either:
Extract your secrets from your codebase (GIT repo), inject them through environment variables at container startup and then access them from your application code like any other environment var. This is not the most secure option, but at least your secrets won't be in your VCS anymore.
Pull the secrets from some type of secrets manager (e.g. AWS Secrets Manager) straight from your application code. This is more secure than the first option, but requires more code changes and creates a dependency between your application and your secrets manager.

How to login remotley to windows from alpine docker image without GUI or SSH

I need to achieve to get an user actively logged into several windows virtual machines from a docker alpine container. I can't use remote desktop, as I have no GUI. I also don't think to really control the Virtual Machines at all, I just need a local user of the virtual machines to be logged in.
How do I achieve that without overcomplicating stuff?
For everyone reading this in the future:
I just activated the autologin feature of Windows 10. In that way, I ensure that my machine always automatically logs in with provided credentials.
To acieve that do the following steps:
Open your registry editor
Navigate to the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogon
If one of the following doesnt exist, just create them:
Edit "DefaultUserName" to the user you want automatcally to log in
Edit "DefaultPassword" to the password of the user you want to log in
Edit "AutoAdminLogon" and change value from 0 to 1
Restart your computer

Docker and SSH for development with phpStorm

I am trying to setup a small development environment using Docker. phpStorm team is working hard on get Docker integrated for remote interpreter and therefore for debugging but sadly is not working yet (see here). The only way I have to add such capabilities for debugging is by creating and enabling an SSH access to the container which works like a charm.
Now, I have read a lot about this and some people like the one on this post says is not recommended. I have read others which says to have a dedicated SSH Docker container which I don't get how to fit on this environment.
I am already creating a user docker-user (check repo here) for certain tasks like run composer without root permissions. That could be used for this SSH stuff easily by adding a default password to it.
How would you handle this under such circumstances?
I too have implemented the ssh server workaround when using jetbrains IDEs.
Usually what I do is add a public ssh key to the ~/.ssh/authorized_keys file for the SSH user in the target container/system, and enable passwordless sudo.
One solution that I've thought of, but not yet had the time to implement, would be to make some sort of SSH service that would be a gateway to a docker exec command. That would potentially allow at least some functionality without having to modify your images in any way for this dev requirement.

How to assign AWS credentials to SYSTEM user?

I have a Powershell script that uploads audit logs to an S3 repository. The script works fine when I run it while logged in but I need to define a scheduled task and the task needs to be run as SYSTEM user. Can someone recommend a way that I can provide the SYSTEM user with the AWS credentials so that they are not stored on the machine in clear text?
I just found what I think is the answer: if I run the script thru the task scheduler once with the 'Set-AWSCredentials' command it creates the encrypted key info in C:\Windows\System32\config\systemprofile\AppData\Local\AWSToolkit\RegisteredAccounts.json. Then I was able to remove the 'Set-AWSCredentials' command and the script seems to run successfully.
I don't believe this is possible. Your authentication info will have to be stored in the clear on the client machine one way or another, and windows doesn't provide any convenient methods for protecting that information.
You might find it more convenient to manage access if you use ssh + encryption certificates as credentials (i believe there's an ssh client for powershell, though i haven't tried using it for aws work)

How can I add private information to OpenShift environment variables?

Authentication information such as database connection strings or passwords should almost never be stored in version control systems.
It looks like the only method of specifying environment variables for an app hosted on OpenShift is to commit them to the Git repository. There is a discussion about this on the OpenShift forums, but no useful suggested workarounds for the problem.
Is there another approach I can use to add authentication information to my app without having to commit it to the repository?
SSH into you application and navigate to your data directory
cd app-root/data
in this directory create a file with your variables (e.g. ".myenv") with content like
export MY_VAR="something"
and then in your repository in ".openshift/action_hooks/pre_start" add this line
source ${OPENSHIFT_DATA_DIR}/.myenv
Openshift supports now setting environment vaiables with the rhc commandline tool like this:
rhc set-env HEROKU_POSTGRESQL_DB_URL='jdbc:postgresql://myurl' -a myapp
I think thats way easier than all the other answers...
See: https://blog.openshift.com/taking-advantage-of-environment-variables-in-openshift-php-apps/
Adding .openshift/action_hooks/pre_start_* is not very cool, because you have to modify your repository in addition to add a file by SSH.
For nodejs, editting nodejs/configuration/node.env works well for some days, but I experienced the file got reverted several times. So it is not stable.
I found a much better solution.
echo -n foobar > ~/.env/user_vars/MY_SECRET
This works perfectly.
(Maybe this is what is done with rhc set-env ...?)
Hope this helps!
Your other option is to create an openshift branch of your project on your local machine. You can create a folder/files for the private information that only lives in your openshift branch. You would still need to source the files in your pre_start hook, something like source ${OPENSHIFT_REPO_DIR}/.private.
Then develop in your master branch, merge into your openshift branch, and push from your openshift branch to OpenShift master branch. This sound convoluted at first, but does make for a very easy workflow, especially if you're origin is shared.
This would be the workflow if your origin was on GitHub.
github/master <--> local/master --> local/openshift --> openshift/master
Notice the only bidirectional link is between github and your local master, so there should be no reason for your credentials to "escape".
This approach also has the added benefit of being able to keep any OpenShift specific changes confined to the openshift branch (like for Gemfiles, ENV variables, paths, etc).
As for security, on the OpenShift server, the repo should have the same security as your $OPENSHIFT_DATA_DIR, so you're not really exposing yourself any more.
Caveat:
Depending on your framework, the files in your $OPENSHIFT_REPO_DIR may be directly accessible via HTTP. You should be able to prevent this with an .htaccess file.

Resources