Script to set http_proxy without password stored in history

When working in an environment that has a proxy it is often very useful and sometimes completely necessary to set your http_proxy system variable so that your Linux machine can access the internet.

But there is a problem with just setting it manually. Take the following example.

You and your team are setting up a Linux machine for dev work and you all know the root credentials and are logging in as root just to set everything up. You want to install a package but can’t get though the proxy. Now here is the problem, you have to set http_proxy to a certain string that will contain your username and password  for you entire network account (email, PCs etc.). If you set the system variable straight from the command line your password will be saved for the rest of your team (or whoever has root access to that Linux machine) to view.

To get around this problem I created a very simple bash script that will set your http_proxy setting for your session and ensure there are no details left behind in the command line history file.

You will need to amend the script where I have highlighted in red.

Ensure you run this with source

(source executes the content of the file in the current shell thread)

source ./

Now to the script


echo "Set http_proxy? y/n"
read yesOrNo

if [ $yesOrNo != "y" ]; then

# Read username
echo -n Username:
read username

# Read password
echo -n Password:
read -s password



export http_proxy

export HISTFILE=$histPath

echo "Testing connection..."

curlOutput=$(curl -I

if [[ $curlOutput == *"407"* ]]
echo "No internet conenction, bad username / password";

if [[ $curlOutput == *"200"* ]]
echo "internet connection OK";

if [[ $curlOutput == *"302"* ]]
echo "internet connection OK";

Setup local Linux git repo to push to GitLab using SSH

If you or your organisation are using GitLab then here are a few steps that you might find useful when creating a repo and pushing it to GitLab.

Firstly create your repo on GitLab from the screen below:


After that your remote repo will be created. We now need to setup git on your dev machine.

The steps below are just for linux as this tutorial is for Linux, windows is covered here(to be completed!).

Setup a git user

git config –global “your name
git config –global “

Create Empty Repository

If you have an existing repo skip this stage.

SSH URLs are strongly recommended.
You will need to add an SSH key for each platform on which you will use git.
cd to your directory where you wish to store you git repo. Create a directory for this project.

mkdir your-project

cd your-project
git init
touch README
git add README
git commit -m ‘first commit’
git remote add origin git@git.domain:group/your-project.git

Existing Git Repo?

cd existing_git_repo
git remote add origin git@git.domain:group/your-project.git
git push -u origin master


Adding SSH key

Before generating an SSH key, check if your system already has one by running:

cat ~/.ssh/

If your see a long string starting with ssh-rsa or ssh-dsa, you can skip the ssh-keygen step.

To generate a new SSH key just open your terminal and use code below. The ssh-keygen command prompts you for a location and filename to store the key pair and for a password. When prompted for the location and filename you can press enter to use the default. It is a best practice to use a password for an SSH key but it is not required and you can skip creating a password by pressing enter. Note that the password you choose here can’t be altered or retrieved.

ssh-keygen -t rsa -C ""

Use the code below to show your public key.

cat ~/.ssh/

Copy-paste the key (copy the complete key starting with ssh- and ending with your username and host).


Navigate to your SSH keys section in your profile on GitLab. Select your profile icon, then the SSH tab  and then Add Key, as highlighted below:


Paste the key into the key text field that appears when you click “Add Key”

Your first push

Now go back to your local git repo directory and run the git push command on the command line. It will ask for your password that you used to create the key.

git push -u origin master

You should now be able to check on GitLab that a commit and push has been completed.

Gedit settings not saving

The Problem

(Just skip to the solution for the commands you need to run to fix this)

I use Gedit over SHH with Xming / X11 running quite regularly and I was not able to save my setting in Gedit. I am running a Red Hat based OS ( such as CentOS and Scientific Linux )

The first error I got was:

GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings will not be saved or shared with other applications.

This tells us that Gedit cannot use the normal GSettings backend to save our settings to disk and is just going to save them to (volatile) memory so when we exit the applicaiton our settings are lost. Not a very clear message at all if you actually want to fix this bug as it gives you no clues that it really wants you to install various other packages (one of them is dconf as we’ll see below).

After searching around I found out i needed to install dconf. After which I got a new error message:

dconf-WARNING **: failed to commit changes to dconf: Failed to execute child process "dbus-launch" (No such file or directory)

Again not very clear… but dconf wants us to install dbus, so I did that and found it was already installed! So I searched Yum and saw a package named dbus-x11. I installed this package and my settings now save.

The solution steps are below.

The Solution

yum install dconf
yum install dconf-editor
yum install dbus
yum install dbus-x11

I hope this helps someone!


Setup FTP on Red Hat based OSs

In this post I’ll go through the very basic steps of how to setup your FTP server on Red Hat based OSs such as CentOS and Scientific Linux.

yum install -y vsftpd
systemctl start vsftpd
systemctl enable vsftpd

Now we need to edit the configuration file here:


Here is my file, the changes I have made are in red and bold.

# Example config file /etc/vsftpd/vsftpd.conf
# The default compiled in settings are fairly paranoid. This sample file
# loosens things up a bit, to make the ftp daemon more usable.
# Please see vsftpd.conf.5 for all compiled in defaults.
# READ THIS: This example file is NOT an exhaustive list of vsftpd options.
# Please read the vsftpd.conf.5 manual page to get a full idea of vsftpd's
# capabilities.
# Allow anonymous FTP? (Beware - allowed by default if you comment this out).
# Uncomment this to allow local users to log in.
# When SELinux is enforcing check for SE bool ftp_home_dir
# Uncomment this to enable any form of FTP write command.
# Default umask for local users is 077. You may wish to change this to 022,
# if your users expect that (022 is used by most other ftpd's)
# Uncomment this to allow the anonymous FTP user to upload files. This only
# has an effect if the above global write enable is activated. Also, you will
# obviously need to create a directory writable by the FTP user.
# When SELinux is enforcing check for SE bool allow_ftpd_anon_write, allow_ftpd_full_access
# Uncomment this if you want the anonymous FTP user to be able to create
# new directories.
# Activate directory messages - messages given to remote users when they
# go into a certain directory.
# Activate logging of uploads/downloads.
# Make sure PORT transfer connections originate from port 20 (ftp-data).
# If you want, you can arrange for uploaded anonymous files to be owned by
# a different user. Note! Using "root" for uploaded files is not
# recommended!
# You may override where the log file goes if you like. The default is shown
# below.
# If you want, you can have your log file in standard ftpd xferlog format.
# Note that the default log file location is /var/log/xferlog in this case.
# You may change the default value for timing out an idle session.
# You may change the default value for timing out a data connection.
# It is recommended that you define on your system a unique user which the
# ftp server can use as a totally isolated and unprivileged user.
# Enable this and the server will recognise asynchronous ABOR requests. Not
# recommended for security (the code is non-trivial). Not enabling it,
# however, may confuse older FTP clients.
# By default the server will pretend to allow ASCII mode but in fact ignore
# the request. Turn on the below options to have the server actually do ASCII
# mangling on files when in ASCII mode.
# Beware that on some FTP servers, ASCII support allows a denial of service
# attack (DoS) via the command "SIZE /big/file" in ASCII mode. vsftpd
# predicted this attack and has always been safe, reporting the size of the
# raw file.
# ASCII mangling is a horrible feature of the protocol.
# You may fully customise the login banner string:
ftpd_banner=Your banner text here.
# You may specify a file of disallowed anonymous e-mail addresses. Apparently
# useful for combatting certain DoS attacks.
# (default follows)
# You may specify an explicit list of local users to chroot() to their home
# directory. If chroot_local_user is YES, then this list becomes a list of
# users to NOT chroot().
# (Warning! chroot'ing can be very dangerous. If using chroot, make sure that
# the user does not have write access to the top level directory within the
# chroot)
# (default follows)
# You may activate the "-R" option to the builtin ls. This is disabled by
# default to avoid remote users being able to cause excessive I/O on large
# sites. However, some broken FTP clients such as "ncftp" and "mirror" assume
# the presence of the "-R" option, so there is a strong case for enabling it.
# When "listen" directive is enabled, vsftpd runs in standalone mode and
# listens on IPv4 sockets. This directive cannot be used in conjunction
# with the listen_ipv6 directive.
# This directive enables listening on IPv6 sockets. By default, listening
# on the IPv6 "any" address (::) will accept connections from both IPv6
# and IPv4 clients. It is not necessary to listen on *both* IPv4 and IPv6
# sockets. If you want that (perhaps because you want to listen on specific
# addresses) then you must run two copies of vsftpd with two configuration
# files.
# Make sure, that one of the listen options is commented !!

Now restart the FTP service:

systemctl restart vsftpd

Create a user for FTP access:

useradd ftpuser
passwd ftpuser

Now you should be able to connect to your FTP server using the above user account (root probably wont’ work, hence the new user). You will need your server IP, to get this you can run ifconfig.

I use FileZilla as an FTP client.

service command depreciated in RHEL based OSs


The service command is no longer valid in red hat based systems such as CentOS and Scientific Linux. You will probably see the message “Redirecting to /bin/systemctl” when you try and start / stop / status a service. So now we have to do it as below:

For example:

service httpd start

Would now be run as below:

systemctl start httpd



chkconfig has also been changed, for example:

chkconfig httpd on


systemctl enable httpd

… and …

chkconfig httpd off


systemctl disable httpd

… and …

chkconfig httpd


systemctl is-enabled httpd

… and …

The below command shows what services are enabled (chkconfig –list):

systemctl list-unit-files --type=service


Hope this helps someone!