Cloud Build Trigger for FTP or SSH deployment - google-cloud-platform

How can I deploy a directory to a FTP or SSH server, with a trigger and cloudbuild.yaml?
So far I can already generate a listing of the files which I'd like to upload:
steps:
- name: 'ubuntu'
entrypoint: 'bash'
args:
- '-c'
- |-
find $_UPLOAD_DIRNAME -exec echo {} >> batch.txt \;
cat ./batch.txt
env:
...

I've came to the conclusion, that I don't want the FTP anti-pattern
and have therefore written an alternate SSH cloudbuild.yaml:
generate a new pair of RSA keys.
use the private key for SSH login.
recursively upload the directory with scp.
run remote commands with ssh.
It logs in as user root, therefore remote /etc/ssh/sshd_config needs PermitRootLogin yes.
My variable substitutions meanwhile look alike this:
And this would be the cloudbuild.yaml, which generally demonstrates how to set up SSH keys:
steps:
- name: 'gcr.io/google.com/cloudsdktool/cloud-sdk:latest'
entrypoint: 'bash'
args:
- '-c'
- |-
echo Deploying $_UPLOAD_DIRNAME # $SHORT_SHA
gcloud config set compute/zone $_COMPUTE_ZONE
gcloud config set project $PROJECT_ID
mkdir -p /builder/home/.ssh
gcloud compute config-ssh
gcloud compute scp --ssh-key-expire-after=$_SSH_KEY_EXPIRE_AFTER --scp-flag="${_SSH_FLAG}" --recurse ./$_UPLOAD_DIRNAME $_COMPUTE_INSTANCE:$_REMOTE_PATH
gcloud compute ssh $_COMPUTE_INSTANCE --ssh-key-expire-after=$_SSH_KEY_EXPIRE_AFTER --ssh-flag="${_SSH_FLAG}" --command="${_SSH_COMMAND}"
env:
- '_COMPUTE_ZONE=$_COMPUTE_ZONE'
- '_COMPUTE_INSTANCE=$_COMPUTE_INSTANCE'
- '_UPLOAD_DIRNAME=$_UPLOAD_DIRNAME'
- '_REMOTE_PATH=$_REMOTE_PATH'
- '_SSH_FLAG=$_SSH_FLAG'
- '_SSH_COMMAND=$_SSH_COMMAND'
- '_SSH_KEY_EXPIRE_AFTER=$_SSH_KEY_EXPIRE_AFTER'
- 'PROJECT_ID=$PROJECT_ID'
- 'SHORT_SHA=$SHORT_SHA'

I've managed to deploy to FTP with ncftp:
first patch /etc/apt/sources.list.
then install ncftp with apt-get.
create the file ~/.ncftp with variable substitutions.
optional step: replace text in files with sed.
recursively upload the directory with ncftpput.
Here's my cloudbuild.yaml (it is working, but the next answer might offer a better solution):
steps:
- name: 'ubuntu'
entrypoint: 'bash'
args:
- '-c'
- |-
echo Deploying ${_UPLOAD_DIRNAME} # ${SHORT_SHA}
echo to ftp://${_REMOTE_ADDRESS}${_REMOTE_PATH}
echo "deb http://archive.ubuntu.com/ubuntu/ focal universe" > /etc/apt/sources.list
apt-get update -y && apt-get install -y ncftp
cat << EOF > ~/.ncftp
host $_REMOTE_ADDRESS
user $_FTP_USERNAME
pass $_FTP_PASSWORD
EOF
# sed -i "s/##_GIT_COMMIT_##/${SHORT_SHA}/g" ./${_UPLOAD_DIRNAME}/plugin.php
ncftpput -f ~/.ncftp -R $_REMOTE_PATH $_UPLOAD_DIRNAME
env:
- '_UPLOAD_DIRNAME=$_UPLOAD_DIRNAME'
- '_REMOTE_ADDRESS=$_REMOTE_ADDRESS'
- '_REMOTE_PATH=$_REMOTE_PATH'
- '_FTP_USERNAME=$_FTP_USERNAME'
- '_FTP_PASSWORD=$_FTP_PASSWORD'
- 'SHORT_SHA=$SHORT_SHA'
Where _REMOTE_PATH is eg. /wp-content/plugins (the variable requires at least one slash) and the _UPLOAD_DIRNAME is the name of the directory within the local Git repository, with no slashes.

Related

Google Cloud Build keeps on giving me 'Can't reach database server at'

So I have been at this for days now almost and it is driving me crazy. Based on other posts, I have set up the following cloudbuild.yaml :
steps:
- name: gcr.io/cloud-builders/docker
args:
- build
- -t
- gcr.io/${INSTANCE_NAME}
- .
- name: gcr.io/cloud-builders/docker
args:
- push
- gcr.io/${INSTANCE_NAME}
- name: 'gcr.io/${INSTANCE_NAME}'
entrypoint: sh
env:
- DATABASE_URL=postgresql://USER:PASSWORD#localhost/DATABASE?host=/cloudsql/CONNECTION_NAME
args:
- -c
- |
wget https://dl.google.com/cloudsql/cloud_sql_proxy.linux.amd64 -O cloud_sql_proxy
chmod +x cloud_sql_proxy
./cloud_sql_proxy -instances=CONNECTION_NAME=tcp:5432 & sleep 3
npx prisma migrate deploy
- name: gcr.io/google.com/cloudsdktool/cloud-sdk
entrypoint: gcloud
args:
- run
- deploy
- backend
- --image
- gcr.io/${INSTANCE_NAME}
- --region
- europe-west1
images:
- gcr.io/${INSTANCE_NAME}
When running this, I am greeted by:
Step #2: 2023/02/05 13:00:49 Listening on 127.0.0.1:5432 for CONNECTION_NAME
Step #2: 2023/02/05 13:00:49 Ready for new connections
Step #2: 2023/02/05 13:00:49 Generated RSA key in 118.117245ms
Step #2: npm WARN exec The following package was not found and will be installed: prisma#4.9.0
Step #2: Prisma schema loaded from prisma/schema.prisma
Step #2: Datasource "db": PostgreSQL database "develop", schema "public" at "localhost"
Step #2:
Step #2: Error: P1001: Can't reach database server at `/cloudsql/CONNECTION_NAME`:`5432`
Step #2:
Step #2: Please make sure your database server is running at `/cloudsql/CONNECTION_NAME`:`5432`.
So even with using the database url hardcoded and with the Cloud SQL proxy working, i am STILL getting this error. What am I missing?
Check for the container-name in .env file and change it to postgres as it would replace name in connection string as discussed here
Or try the following format if you don’t want to hardcode IP address
DB_USER=dbuser
DB_PASS=dbpass
DB_HOST=localhost
DB_PORT=5432
CLOUD_SQL_CONNECTION_NAME=/cloudsql/gcp-project-id:europe-west3:db-instance-name
DATABASE_URL=postgres://${DB_USER}:${DB_PASS}#${DB_HOST}:${DB_PORT}/${DB_BASE}?host=${CLOUD_SQL_CONNECTION_NAME}
If you have public IP try connecting by unix socket

GCP Helm Cloud Builder

Just curious, why isn't there a helm cloud builder officially supported? It seems like a very common requirement, yet I'm not seeing one in the list here:
https://github.com/GoogleCloudPlatform/cloud-builders
I was previously using alpine/helm in my cloudbuild.yaml for my helm deployment as follows:
steps:
# Build app image
- name: gcr.io/cloud_builders/docker
args:
- build
- -t
- $_IMAGE_REPO/$_CONTAINER_NAME:$COMMIT_SHA
- ./cloudbuild/$_CONTAINER_NAME/
# Push my-app image to Google Cloud Registry
- name: gcr.io/cloud-builders/docker
args:
- push
- $_IMAGE_REPO/$_CONTAINER_NAME:$COMMIT_SHA
# Configure a kubectl workspace for this project
- name: gcr.io/cloud-builders/kubectl
args:
- cluster-info
env:
- CLOUDSDK_COMPUTE_REGION=$_CUSTOM_REGION
- CLOUDSDK_CONTAINER_CLUSTER=$_CUSTOM_CLUSTER
- KUBECONFIG=/workspace/.kube/config
# Deploy with Helm
- name: alpine/helm
args:
- upgrade
- -i
- $_CONTAINER_NAME
- ./cloudbuild/$_CONTAINER_NAME/k8s
- --set
- image.repository=$_IMAGE_REPO/$_CONTAINER_NAME,image.tag=$COMMIT_SHA
- -f
- ./cloudbuild/$_CONTAINER_NAME/k8s/values.yaml
env:
- KUBECONFIG=/workspace/.kube/config
- TILLERLESS=false
- TILLER_NAMESPACE=kube-system
- USE_GKE_GCLOUD_AUTH_PLUGIN=True
timeout: 1200s
substitutions:
# substitutionOption: ALLOW_LOOSE
# dynamicSubstitutions: true
_CUSTOM_REGION: us-east1
_CUSTOM_CLUSTER: demo-gke
_IMAGE_REPO: us-east1-docker.pkg.dev/fakeproject/my-docker-repo
_CONTAINER_NAME: app2
options:
logging: CLOUD_LOGGING_ONLY
# In this option we are providing the worker pool name that we have created in the previous step
workerPool:
'projects/fakeproject/locations/us-east1/workerPools/cloud-build-pool'
And this was working with no issues. Then recently it just started failing with the following error so I'm guessing a change was made recently:
Error: Kubernetes cluster unreachable: Get "https://10.10.2.2/version": getting credentials: exec: executable gke-gcloud-auth-plugin not found"
I get this error regularly on VM's and can workaround it by setting USE_GKE_GCLOUD_AUTH_PLUGIN=True, but that does not seem to fix the issue here if I add it to the env section. So I'm looking for recommendations on how to use helm with Cloud Build. alpine/helm was just something I randomly tried and was working for me up until now, but there's probably better solutions out there.
Thanks!

How to copy the template sites_enabled.j2 into a /etc/nginx/sites-enabled/default using adhoc commands. & How to start nginx using shell?

The template gets copied normally in /etc/nginx/sites-enabled
On running this command: ansible localhost -b -m copy -a "src=/abc/efg/ngs/templates/sites-enabled.j2 dest=/etc/nginx/sites-enabled"
The file gets copied.
:/etc/nginx/sites-enabled$ ls gives the output as default & sites-enabled.j2.
How to copy the template provided in /ngs to /etc/nginx/sites-enabled/default and how to start the nginx using adhoc the commands?
What I understood from your question is that:
You want to copy multiple template files from
src = "/abc/efg/ngs/" to dest = "/etc/nginx/sites-enabled/default".
You want to restart Nginx.
To achieve this using Adhoc command:
COPY FILES: ansible localhost -b -m copy -a "src=/abc/efg/ngs/templates dest=/etc/nginx/sites-enabled/default/
START NGINX USING COMMAND MODULE: ansible localhost -m command -a "systemctl start nginx"
START NGINX USING SHELL MODULE: ansible localhost -m shell -a "systemctl start nginx"
Ref to ad-hoc commands: https://docs.ansible.com/ansible/latest/user_guide/intro_adhoc.html
To achieve this using the playbook command:
- name: Copying files from source to destination
copy:
src: /abc/efg/ngs/templates
dest: /etc/nginx/sites-enabled/default/
owner: foo
group: foo
mode: 0644
- name: Starting nginx
command: systemctl start nginx
Ref: https://docs.ansible.com/ansible/2.4/copy_module.html
Ref: https://docs.ansible.com/ansible/latest/collections/ansible/builtin/command_module.html
But rather I would suggest If you learn about handlers as they are very much helpful to do these kinds of tasks when you want to restart/reload any service only when a change happens.
Ref: https://docs.ansible.com/ansible/latest/user_guide/playbooks_handlers.html
If you asked something else, let me know.

Why doesn't certbot-dns-cloudflare plugin install under aws linux

I have an elastic beanstalk with a single ec2 instance and I need to install an SSL certificate during deployment and at this time the server can't be reached via the ip address given by the A record on the DNS. I would like to use LetsEncrypt with the certbot-dns-cloudflare plugin to automatically get and install a certificate. I have created a cloudflare credentials file containing my cloudflare api key so that the plugin can request cloudflare to create a DNS TXT record and use it to do the domain name ownership validation.
I encountered a number of problems when attempting to install certbot using the method described here https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/SSL-on-an-instance.html#letsencrypt (EPEL libraries not containing certbot), and appeared to have better luck using the cerbot-auto install method here https://medium.com/#mohan08p/install-and-renew-lets-encrypt-ssl-on-amazon-ami-6d3e0a61693.
So my process so far is:
$ wget https://dl.eff.org/certbot-auto
$ chmod a+x certbot-auto
$ sudo ./certbot-auto --debug --install-only
This appears to get certbot installed and I see no error messages.
Next I do this:
$ cd /opt/eff.org/certbot/venv
$ source bin/activate
$ sudo pip install certbot-dns-cloudflare
... cut short for brevity ...
Collecting zope.event (from zope.component->certbot>=0.21.1->certbot-dns-cloudflare)
Downloading https://files.pythonhosted.org/packages/c5/96/361edb421a077a4c208b4a5c212737d78ae03ce67fbbcd01621c49f332d1/zope.event-4.4-py2.py3-none-any.whl
Collecting pycparser (from cffi!=1.11.3,>=1.7->cryptography>=0.8->acme>=0.21.1->certbot-dns-cloudflare)
Downloading https://files.pythonhosted.org/packages/68/9e/49196946aee219aead1290e00d1e7fdeab8567783e83e1b9ab5585e6206a/pycparser-2.19.tar.gz (158kB)
100% |################################| 163kB 7.9MB/s
Collecting zope.proxy (from zope.deferredimport>=4.2.1->zope.component->certbot>=0.21.1->certbot-dns-cloudflare)
Downloading https://files.pythonhosted.org/packages/7c/f5/e9ed65cdf8c93d24d7512ef89e21b241bc9ae75d90bc8608cc142f4c26f9/zope.proxy-4.3.1.tar.gz (43kB)
100% |################################| 51kB 12.1MB/s
Installing collected packages: funcsigs, pbr, six, mock, zope.interface, chardet, idna, certifi, urllib3, asn1crypto, enum34, pycparser, cffi, ipaddress, cryptography, PyOpenSSL, requests, requests-toolbelt, pytz, pyrfc3339, josepy, acme, future, parsedatetime, ConfigArgParse, zope.hookable, zope.proxy, zope.deferredimport, zope.deprecation, zope.event, zope.component, certbot, jsonlines, cloudflare, certbot-dns-cloudflare
Found existing installation: six 1.8.0
Uninstalling six-1.8.0:
Successfully uninstalled six-1.8.0
Found existing installation: chardet 2.0.1
DEPRECATION: Uninstalling a distutils installed project (chardet) has been deprecated and will be removed in a future version. This is due to the fact that uninstalling a distutils project will only partially uninstall the project.
Uninstalling chardet-2.0.1:
Successfully uninstalled chardet-2.0.1
Found existing installation: urllib3 1.8.2
Uninstalling urllib3-1.8.2:
Successfully uninstalled urllib3-1.8.2
Running setup.py install for pycparser ... done
Found existing installation: requests 1.2.3
Uninstalling requests-1.2.3:
Successfully uninstalled requests-1.2.3
Running setup.py install for future ... done
Running setup.py install for ConfigArgParse ... done
Running setup.py install for zope.hookable ... done
Running setup.py install for zope.proxy ... done
Running setup.py install for cloudflare ... done
Successfully installed ConfigArgParse-0.13.0 PyOpenSSL-18.0.0 acme-0.29.1 asn1crypto-0.24.0 certbot-0.29.1 certbot-dns-cloudflare-0.29.1 certifi-2018.11.29 cffi-1.11.5 chardet-3.0.4 cloudflare-2.1.0 cryptography-2.4.2 enum34-1.1.6 funcsigs-1.0.2 future-0.17.1 idna-2.8 ipaddress-1.0.22 josepy-1.1.0 jsonlines-1.2.0 mock-2.0.0 parsedatetime-2.4 pbr-5.1.1 pycparser-2.19 pyrfc3339-1.1 pytz-2018.7 requests-2.21.0 requests-toolbelt-0.8.0 six-1.12.0 urllib3-1.24.1 zope.component-4.5 zope.deferredimport-4.3 zope.deprecation-4.4.0 zope.event-4.4 zope.hookable-4.2.0 zope.interface-4.6.0 zope.proxy-4.3.1
You are using pip version 9.0.3, however version 18.1 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.
In the listing I see indications that the cloudflare plugin was successfully installed. However, when I list the plugins I don't see it:
$ sudo ./certbot-auto plugins
Saving debug log to /var/log/letsencrypt/letsencrypt.log
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
* apache
Description: Apache Web Server plugin
Interfaces: IAuthenticator, IInstaller, IPlugin
Entry point: apache = certbot_apache.entrypoint:ENTRYPOINT
* nginx
Description: Nginx Web Server plugin
Interfaces: IAuthenticator, IInstaller, IPlugin
Entry point: nginx = certbot_nginx.configurator:NginxConfigurator
* standalone
Description: Spin up a temporary webserver
Interfaces: IAuthenticator, IPlugin
Entry point: standalone = certbot.plugins.standalone:Authenticator
* webroot
Description: Place files in webroot directory
Interfaces: IAuthenticator, IPlugin
Entry point: webroot = certbot.plugins.webroot:Authenticator
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Attempts to run certbot-auto using the plugin fail as follows:
$ sudo ./certbot-auto certonly --dns-cloudflare --dns-cloudflare-credentials ~/.secrets/certbot/cloudflare.ini --dns-cloudflare-propagation-seconds 60 -d my-domain.com
usage:
certbot-auto [SUBCOMMAND] [options] [-d DOMAIN] [-d DOMAIN] ...
Certbot can obtain and install HTTPS/TLS/SSL certificates. By default,
it will attempt to use a webserver both for obtaining and installing the
certificate.
certbot: error: unrecognized arguments: --dns-cloudflare-credentials /home/ec2-user/.secrets/certbot/cloudflare.ini --dns-cloudflare-propagation-seconds 60
Can anyone advise?
Thanks
This is what worked for me in the end:
$ wget https://dl.eff.org/certbot-auto
$ chmod a+x certbot-auto
$ sudo ./certbot-auto --debug --install-only
$ whereis certbot
certbot: /usr/local/bin/certbot
$ cd /opt/eff.org/certbot/venv
$ source bin/activate
$ sudo pip install certbot-dns-cloudflare
$ deactivate
$ sudo /usr/local/bin/certbot plugins
Saving debug log to /var/log/letsencrypt/letsencrypt.log
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
* dns-cloudflare
Description: Obtain certificates using a DNS TXT record (if you are using
Cloudflare for DNS).
Interfaces: IAuthenticator, IPlugin
Entry point: dns-cloudflare =
certbot_dns_cloudflare.dns_cloudflare:Authenticator
* standalone
Description: Spin up a temporary webserver
Interfaces: IAuthenticator, IPlugin
Entry point: standalone = certbot.plugins.standalone:Authenticator
* webroot
Description: Place files in webroot directory
Interfaces: IAuthenticator, IPlugin
Entry point: webroot = certbot.plugins.webroot:Authenticator
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If incorporating this in .ebextensions/01-packages/install-packages.conf which will be run under root, you'll need to add something to create the following file containing your cloudflare email and api key at /root/.secrets/certbot/cloudflare.ini
$ sudo mkdir /root/.secrets/certbot
$ sudo chmod 700 /.secrets
$ sudo su
# printf 'dns_cloudflare_email = <your-cf-email>\ndns_cloudflare_api_key = <your-cf-api-key' > /root/.secrets/certbot/cloudflare.ini
# printf 'A\nn\nn\n' | /usr/local/bin/certbot certonly --dns-cloudflare --dns-cloudflare-credentials ~/.secrets/certbot/cloudflare.ini --dns-cloudflare-propagation-seconds 60 -d my-domain.com
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator dns-cloudflare, Installer None
Obtaining a new certificate
Performing the following challenges:
dns-01 challenge for my-domain.com
Waiting 60 seconds for DNS changes to propagate
Waiting for verification...
Cleaning up challenges
IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/my-domain.com/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/my-domain.com/privkey.pem
Your cert will expire on 2019-03-17. To obtain a new or tweaked
version of this certificate in the future, simply run certbot
again. To non-interactively renew *all* of your certificates, run
"certbot renew"
- If you like Certbot, please consider supporting our work by:
Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le
I had the same issue trying to install cerbot cloudflare plugin on Amazon Linux. I tried a few different things but the following worked using pip i.e.
sudo yum install -y python-pip
pip install --upgrade pip
pip install certbot-dns-cloudflare
For me certbot was installed in two locations /usr/local/bin/certbot which worked and the default /usr/bin/certbot which couldn't find the newly installed plugins.
I was using which certbot, certbot plugins, and /usr/local/bin/certbot plugins to debug this.
Hope this helps someone.

Docker env variables not set while log via shell

In my settings file i am getting env variables like this
'NAME': os.environ['PG_DBNAME'], # Database
I am setting in docker file like this
-e PG_DBNAME= "mapp"
Now
The web app work fine
If i log into shell via docker exec ... bash then env variables are also set
But if i log in via ipaddress and port number from ssh client then i am able to login but env variables are not set
As commented in issue 2569:
This is expected. SSH wipes out the environment as part of the login process.
One way to work around it is to dump the environment variables in /etc/environment (e.g. env | grep _ >> /etc/environment) before starting Supervisor.
Further "login processes" should source this file, and tada! There is your environment.
That env | grep _ >> /etc/environment could be part of a default run script associated (through ENTRYPOINT or CMD) to your image.
Daniel A.A. Pelsmaeker suggests jenkinsci/docker-ssh-agent issue 33 for an approach that selects and sets all environment variables excluding a specific denylist:
For my own uses I changed that line to the following:
env | egrep -v "^(HOME=|USER=|MAIL=|LC_ALL=|LS_COLORS=|LANG=|HOSTNAME=|PWD=|TERM=|SHLVL=|LANGUAGE=|_=)" >> /etc/environment
This takes all environment variables, except those listed, and appends then to /etc/environment, overriding any previously defined there.
I also had the exact same problem. I found the example on docs.docker.com appending variables by echo'ing to /etc/profile not the nicest way to do that. So here is my solution:
Dockerbuild:
I execute the docker build by the following command which also fetches the http_proxy, https_proxy and no_proxy variables from the
current shell session. The variables are passed as agruments with the --build-arg option.
[root#localhost dock-centOS]# docker build
--build-arg http_proxy="{{ lookup('env', 'http_proxy')}}"
--build-arg https_proxy="{{ lookup('env', 'https_proxy')}}"
--build-arg no_proxy="{{ lookup('env', 'no_proxy')}}"
-t my_pv_repo:centOS-with-sshd .
Dockerfile:
I use the following dockerfile snippet for setting the enviroment variables for all users. The ARG command is used instead of
ENV because i don't want docker to persist my variables in the image. The ARG variable is only available during the docker build.
The RUN command creates a bash script which is placed in the /etc/profile.d directory. During start-up of the container
/etc/profile script is run and sources all readable files in the /etc/profile.d directory.
FROM centos:7.3.1611
ARG http_proxy=$http_proxy
ARG https_proxy=$https_proxy
ARG no_proxy=$no_proxy
ARG JAVA_HOME=/usr/lib/jvm/jdk1.6.0_45
ARG DOMAIN_HOME=/home/oracle/w001/D1/app/user_projects/domains/fancy_app_domain
ARG PATH=$PATH:/usr/lib/jvm/jdk1.6.0_45/bin
ARG XAUTHORITY=~/.Xauthority
RUN shebang='#!/usr/bin/env bash'; \
env_vars="export http_proxy=${http_proxy} https_proxy=${https_proxy} no_proxy=${no_proxy}"; \
env_vars+=' JAVA_HOME=/usr/lib/jvm/jdk1.6.0_45 DOMAIN_HOME=/home/oracle/w001/D1/app/user_projects/domains/fancy_app_domain'; \
env_vars+=" PATH=${PATH}:/usr/lib/jvm/jdk1.6.0_45/bin XAUTHORITY=${XAUTHORITY}"; \
echo $shebang$'\n'$env_vars > /etc/profile.d/env_vars.sh
Test result: Well lets hit the cli to check if our environment variables are available during a ssh session.
[root#localhost vagrant]# docker exec -u root -it centOS-container bash
[root#33e7efab489c /]#
[root#33e7efab489c /]#
[root#33e7efab489c /]# cat /etc/profile.d/env_vars.sh
#!/usr/bin/env bash
export http_proxy=http://10.0.2.2:3128 https_proxy=http://10.0.2.2:3128 no_proxy=localhost,127.0.0.1 JAVA_HOME=/usr/lib/jvm/jdk1.6.0_45 DOMAIN_HOME=/home/oracle/w001/D1/app/user_projects/domains/fancy_app_domain PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/lib/jvm/jdk1.6.0_45/bin XAUTHORITY=~/.Xauthority
[root#33e7efab489c /]#
[root#33e7efab489c /]#
[root#33e7efab489c /]# printenv
HOSTNAME=33e7efab489c
TERM=xterm
http_proxy=http://10.0.2.2:3128
LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=01;05;37;41:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=01;36:*.au=01;36:*.flac=01;36:*.mid=01;36:*.midi=01;36:*.mka=01;36:*.mp3=01;36:*.mpc=01;36:*.ogg=01;36:*.ra=01;36:*.wav=01;36:*.axa=01;36:*.oga=01;36:*.spx=01;36:*.xspf=01;36:
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/lib/jvm/jdk1.6.0_45/bin
DOMAIN_HOME=/home/oracle/w001/D1/app/user_projects/domains/fancy_app_domain
PWD=/
JAVA_HOME=/usr/lib/jvm/jdk1.6.0_45
LANG=en_US.UTF-8
https_proxy=http://10.0.2.2:3128
SHLVL=1
HOME=/root
no_proxy=localhost,127.0.0.1
XAUTHORITY=/root/.Xauthority
_=/usr/bin/printenv
[root#33e7efab489c /]#
[root#33e7efab489c /]#
[root#33e7efab489c /]# exit
[root#localhost vagrant]# exit
[vagrant#localhost ~]$ logout
Connection to 127.0.0.1 closed.
me#my-mac$ ssh -X root#localhost -p 7022 -o UserKnownHostsFile=/dev/null -o IdentityFile=/development/workspace/supercalifragilisticexpialidocious-app/.vagrant/machines/default/virtualbox/private_key
The authenticity of host '[localhost]:7022 ([127.0.0.1]:7022)' can't be established.
ECDSA key fingerprint is SHA256:dTd/vsmPTbrA3kPeIfArZMFEgfdlgjGHwMgE3Z5BgBc.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[localhost]:7022' (ECDSA) to the list of known hosts.
/usr/bin/xauth: file /root/.Xauthority does not exist
[root#33e7efab489c ~]# su - oracle
bash-4.2$
bash-4.2$
bash-4.2$ printenv
HOSTNAME=33e7efab489c
SHELL=/bin/bash
TERM=xterm-256color
HISTSIZE=1000
http_proxy=http://10.0.2.2:3128
USER=oracle
LS_COLORS=rs=0:di=38;5;27:ln=38;5;51:mh=44;38;5;15:pi=40;38;5;11:so=38;5;13:do=38;5;5:bd=48;5;232;38;5;11:cd=48;5;232;38;5;3:or=48;5;232;38;5;9:mi=05;48;5;232;38;5;15:su=48;5;196;38;5;15:sg=48;5;11;38;5;16:ca=48;5;196;38;5;226:tw=48;5;10;38;5;16:ow=48;5;10;38;5;21:st=48;5;21;38;5;15:ex=38;5;34:*.tar=38;5;9:*.tgz=38;5;9:*.arc=38;5;9:*.arj=38;5;9:*.taz=38;5;9:*.lha=38;5;9:*.lz4=38;5;9:*.lzh=38;5;9:*.lzma=38;5;9:*.tlz=38;5;9:*.txz=38;5;9:*.tzo=38;5;9:*.t7z=38;5;9:*.zip=38;5;9:*.z=38;5;9:*.Z=38;5;9:*.dz=38;5;9:*.gz=38;5;9:*.lrz=38;5;9:*.lz=38;5;9:*.lzo=38;5;9:*.xz=38;5;9:*.bz2=38;5;9:*.bz=38;5;9:*.tbz=38;5;9:*.tbz2=38;5;9:*.tz=38;5;9:*.deb=38;5;9:*.rpm=38;5;9:*.jar=38;5;9:*.war=38;5;9:*.ear=38;5;9:*.sar=38;5;9:*.rar=38;5;9:*.alz=38;5;9:*.ace=38;5;9:*.zoo=38;5;9:*.cpio=38;5;9:*.7z=38;5;9:*.rz=38;5;9:*.cab=38;5;9:*.jpg=38;5;13:*.jpeg=38;5;13:*.gif=38;5;13:*.bmp=38;5;13:*.pbm=38;5;13:*.pgm=38;5;13:*.ppm=38;5;13:*.tga=38;5;13:*.xbm=38;5;13:*.xpm=38;5;13:*.tif=38;5;13:*.tiff=38;5;13:*.png=38;5;13:*.svg=38;5;13:*.svgz=38;5;13:*.mng=38;5;13:*.pcx=38;5;13:*.mov=38;5;13:*.mpg=38;5;13:*.mpeg=38;5;13:*.m2v=38;5;13:*.mkv=38;5;13:*.webm=38;5;13:*.ogm=38;5;13:*.mp4=38;5;13:*.m4v=38;5;13:*.mp4v=38;5;13:*.vob=38;5;13:*.qt=38;5;13:*.nuv=38;5;13:*.wmv=38;5;13:*.asf=38;5;13:*.rm=38;5;13:*.rmvb=38;5;13:*.flc=38;5;13:*.avi=38;5;13:*.fli=38;5;13:*.flv=38;5;13:*.gl=38;5;13:*.dl=38;5;13:*.xcf=38;5;13:*.xwd=38;5;13:*.yuv=38;5;13:*.cgm=38;5;13:*.emf=38;5;13:*.axv=38;5;13:*.anx=38;5;13:*.ogv=38;5;13:*.ogx=38;5;13:*.aac=38;5;45:*.au=38;5;45:*.flac=38;5;45:*.mid=38;5;45:*.midi=38;5;45:*.mka=38;5;45:*.mp3=38;5;45:*.mpc=38;5;45:*.ogg=38;5;45:*.ra=38;5;45:*.wav=38;5;45:*.axa=38;5;45:*.oga=38;5;45:*.spx=38;5;45:*.xspf=38;5;45:
MAIL=/var/spool/mail/oracle
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/lib/jvm/jdk1.6.0_45/bin
DOMAIN_HOME=/home/oracle/w001/D1/app/user_projects/domains/fancy_app_domain
PWD=/home/oracle
JAVA_HOME=/usr/lib/jvm/jdk1.6.0_45
LANG=en_US.UTF-8
https_proxy=http://10.0.2.2:3128
HISTCONTROL=ignoredups
SHLVL=1
HOME=/home/oracle
no_proxy=localhost,127.0.0.1
LOGNAME=oracle
XAUTHORITY=/home/oracle/.Xauthority
_=/usr/bin/printenv