Install Jenkins on Ubuntu 16.04

This is what I did to get a functioning Jenkins server on Ubuntu 16.04 LTS.

1) I installed the default Java that comes with Ubuntu:
sudo apt-get install default-jdk
2) Test with “java -version”

This gave me version 1.8.0_91 which worked fine for Jenkins.

3) Next I added a new repository using a PPA package.

  1. wget -q -O – http://pkg.jenkins-ci.org/debian-stable/jenkins-ci.org.key | sudo apt-key add –
  2. sudo sh -c ‘echo deb http://pkg.jenkins-ci.org/debian-stable binary/ > /etc/apt/sources.list.d/jenkins.list’

4) Update with “sudo apt-get update”
5) Now install Jenkins using this new repo.
sudo apt-get install jenkins
This will create a new user = jenkins user with

 

  • home=/var/lib/jenkins
  • startup script= /etc/init.d/jenkins

6) Enable jenkins to start at boot with:
sudo systemctl enable jenkins.service
other systemctl commands:

  • sudo systemctl start jenkins.service
  • sudo systemctl status jenkins.service
  • sudo systemctl stop jenkins.service

Bugzilla Passwords Lost

I had a situation where we had an old Bugzilla server that hadn’t been used for several years. As these things often happen, the “powers that be” suddenly decided we need that server to be back up and running NOW. Of course, nobody could remember their passwords any more and the email password mechanism had stopped working.

A Google search could only seem to turn up suggestions that started with “login to an admin user…”. Yeah, if I could do that I wouldn’t really have problem would I?

Anyway the solution was fairly easy actually.

NOTE: this is a dangerous solution that leaves the admin user exposed for a little while. Take reasonable precautions to prevent access until finished. Either with firewall rules or via an Apache .htaccess rule.

  1. Sign on to Mysql via the command line on the server in question
  2. USE bugs; (the bugzilla database)
    UPDATE profiles SET cryptpassword=null WHERE userid=1;
    QUIT;
  3. userid is the id of an admin user

  4. You can now login as that user with no password (see I told you it was dangerous).
  5. As admin you can change the password of another user to a password you can rememeber, so do that.
  6. Now if you go back into the database and list everything you will see the encrypted passwords.
  7. Now just set the password for your admin user and use the encrypted string in place of null in the above SQL statement.
  8. Once you have set the encrypted password you should be able to login as the admin user using the password you set and you can even change the password at this point.

Postfix and LDAP

POSTFIX was already installed in a simple fashion using real Unix accounts. We will continue to use these Unix accounts but pass authentication duties off to an LDAP server.

I used the Centos Directory Server and it was necessary to install the (75misc.ldif schema in the server to allow for mail aliases and mailing lists).

/etc/postix/master.cf was not changed for this set-up.

The following settings were placed in
/etc/postfix/main.cf:

queue_directory = /var/spool/postfix
command_directory = /usr/sbin
daemon_directory = /usr/libexec/postfix
mail_owner = postfix
myhostname = vm239.example.com
mydomain = example.com
myorigin = $mydomain
inet_interfaces = all

mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain

unknown_local_recipient_reject_code = 550
mynetworks_style = subnet
#mynetworks = 10.200.3.0/24, 127.0.0.0/8

alias_maps = hash:/etc/aliases
alias_database = $alias_maps
local_recipient_maps = ldap:/etc/postfix/ldap-users.cf
home_mailbox = Maildir/
virtual_alias_maps = ldap:/etc/postfix/ldap-aliases.cf
newaliases_path = /usr/bin/newaliases.postfix

# Virtual Users
# I didn’t use this but it could be used
#

#virtual_mailbox_domains = virtual.com
#virtual_mailbox_base = /var/spool/virt_mailboxes/
#virtual_mailbox_maps = hash:/etc/postfix/vmailbox
#virtual_mailbox_maps = ldap:/etc/postfix/ldap-users.cf
#virtual_minimum_uid = 100
#virtual_uid_maps = static:500
#virtual_gid_maps = static:500
#virtual_alias_domains = virtual.com
#virtual_alias_maps = hash:/etc/postfix/valias

This was added to the bottom of the /etc/aliases file but otherwise it was left as installed (note: run the newaliases command after any changes are made to the aliases file).

root: tedc

/etc/postfix/ldap-users.cf

bind = no
version = 3
timeout = 20
size_limit = 1
expansion_limit = 0
start_tls = no
tls_require_cert = no
server_host = ldap://vm241.example.com/
scope = sub
search_base = ou=people,dc=example,dc=com
query_filter = (mail=%s)
result_attribute = uid

/etc/ldap-aliases.cf

bind = no
timeout = 20
server_host = ldap://vm241.example.com
search_base = ou=aliases,dc=example,dc=com
scope = sub
version = 3
query_filter = (cn=%s)
result_attribute = rfc822MailMember

Facebook Security

I just came across what I feel is a good setting for most Facebook users. It allows you to get an email notification of anyone using your Facebook account from an unauthorized computer. I personally use a number of computers to update my Facebook status but, I still want to get notified every time something happens outside of my main computer (and hopefully I can register my laptop also).

You go to:

ACCOUNT > ACCOUNT SETTINGS > ACCOUNT SECURITY

click the CHANGE button

The setting is “Would you like to receive notifications for logins from new devices?

Select YES

Then LOGOUT of FACEBOOK.

When you first log back in to FACEBOOK you will be asked to verify and name that device.

Give it a meaningful name and Voila.

I will be testing this to see how annoying the notifications are but, it looks good.

Downgrade Virtualmin pt3

Okay its seems that the virtualmin downgrade has settled down now.
I’m still working out exactly how much functionality I have lost by going to the free GPL version but this is what I did:
After installing the RPM I downloaded the repo and installed it with:
rpm -Uvh –oldpackage virtualmin-release-latest.rpm
I then ran a
yum clean all
This will clean up the repo settings left over from the downgrade and reset to the gpl version.
You then need to go into the webmin control panel
WEBMIN>SYSTEM>Scheduled Cron Jobs
and disable the following cron jobs that are not offered in the gpl version:
sendratings.pl
maillog.pl
fcgiclear.pl
The last one is a clean up program for fastcgi but , I haven’t found out what the other 2 jobs do.
I just know that they give me errors in my logs if left enabled.
Ted

Okay its seems that the Virtualmin downgrade has settled down now.

I’m still working out exactly how much functionality I have lost by going to the free GPL version but this is what I did:

  • I downloaded the repo rpm and installed it with:

rpm -Uvh –oldpackage virtualmin-release-latest.rpm

  • I then ran a

yum clean all

This will clean up the repo settings left over from the downgrade and reset to the gpl version.

I then went into the webmin control panel:

WEBMIN>SYSTEM>Scheduled Cron Jobs

and disabled the following cron jobs (these are apparently not valid in the gpl version of Virtualmin):

  1. sendratings.pl
  2. maillog.pl
  3. fcgiclear.pl

That last one is a clean up program for fastcgi but , I haven’t found out what the other 2 jobs do.

I just know that they give me errors in my logs if left enabled.

I have since discovered that it might be possible to change the username and password to “GPL” and the re-run the install script. I have not tested this and don’t know what that would do to the existing servers, mailpacks , etc.

Downgrade Virtualmin pt.2

Okay so it turns out the upgrade (downgrade..sidegrade???) to Virtualmin didn’t work as well as I had hoped.

I did the steps outlined previously but some problems cropped up.

  1. Some hourly cron jobs started to act up (most notably one which cleans up Fastcgi scripts …fcgiclean.pl)
  2. The Virtualmin Control Panel announced a new   update which , when applied, actually reverted back to the Pro version and then proceeded to warn me that the license was out of date …again…sigh

I will troll the support forums and see if I can fix this.

Also unfortunately Virtualmin seems to be updating their website so their support documentation is full of stale links…double sigh.

I will keep posting here.

Downgrade Virtualmin

I recently had to downgrade our Virtualmin package from PRO to GPL because our license expired and we didn’t seem to need the features of the PRO version any more.

Time will tell if this turns out to be a foolish move but this is what I did.
Basically you just install the GPL version over top of the PRO version.
Exactly how you downgrade depends on your OS, and how you installed.
For an RPM-based Distro like Centos 5, you’ll have to use the “–old-package”
option to RPM to install the GPL version. Because upgrading is the far more
common path, Professional has a higher Epoch than GPL, which means it always
looks like a newer version to rpm/yum, even if it isn’t.
The GPL repository has the exact same URL as the Professional one, except it
has “/gpl/” at the beginning of the path.
Steps I took:
ONE
First install the GPL version over the PRO version;
Download from
http://software.virtualmin.com/gpl/centos/5/i386/
e.g. wbm-virtual-server-3.73.gpl-1.noarch.rpm
rpm -Uvh –oldpackage wbm-virtual-server-“VERS#”.noarch.rpm
Obviously, with GPL, you don’t need a serial number or license key in the URL
TWO
Then upgrade the repo with:
rpm -Uvh –oldpackage http://software.virtualmin.com/gpl/
centos/5/i386/virtualmin-release-latest.noarch.rpm
THREE
Then do a
yum update
…and finally REBOOT if a new kernel was installed.
I recently had to downgrade our Virtualmin package from PRO to GPL because our license expired and we didn’t seem to need the features of the PRO version any more.
Time will tell if this turns out to be a foolish move but this is what I did.
Basically you just install the GPL version over top of the PRO version.
Exactly how you downgrade depends on your OS, and how you installed.
For an RPM-based Distro like Centos 5, you’ll have to use the “–old-package”
option to RPM to install the GPL version. Because upgrading is the far more
common path, Professional has a higher Epoch than GPL, which means it always
looks like a newer version to rpm/yum, even if it isn’t.
The GPL repository has the exact same URL as the Professional one, except it
has “/gpl/” at the beginning of the path.
Steps I took:
ONE
First install the GPL version over the PRO version;
Download from
http://software.virtualmin.com/gpl/centos/5/i386/
e.g. wbm-virtual-server-3.73.gpl-1.noarch.rpm
rpm -Uvh –oldpackage wbm-virtual-server-“VERS#”.noarch.rpm
Obviously, with GPL, you don’t need a serial number or license key in the URL
TWO
Then upgrade the repo with:
rpm -Uvh –oldpackage http://software.virtualmin.com/gpl/
centos/5/i386/virtualmin-release-latest.noarch.rpm
THREE
Then do a
yum update
…and finally REBOOT if a new kernel was installed.

Time will tell if this turns out to be a foolish move but this is what I did.

Basically you just install the GPL version over top of the PRO version, how you downgrade depends on your OS. For an RPM-based Distro like Centos 5, you’ll have to use the “–old-package” option to RPM to install the GPL version. Because upgrading is the far more common scenario, PRO has a higher Epoch than GPL, which means it always looks like a newer version to rpm/yum, even if it actually  isn’t.

The GPL repository will have the same URL as the Professional one, except it

has “/gpl/” in the path.

Steps I took:

ONE

First install the GPL version over the PRO version;

Download from

http://software.virtualmin.com/gpl/centos/5/i386/

e.g. wbm-virtual-server-3.73.gpl-1.noarch.rpm

rpm -Uvh –oldpackage wbm-virtual-server-“VERS#”.noarch.rpm

Obviously, with GPL, you won’t need a serial number to download it.

TWO

Then upgrade the repo with:

rpm -Uvh –oldpackage http://software.virtualmin.com/gpl/

centos/5/i386/virtualmin-release-latest.noarch.rpm

THREE

Then do a

yum update

…and finally REBOOT if a new kernel was installed.

Tar Command

The TAR command is one of those built-in utilities that makes Linux (and of course UNIX) so great. It allows you to make an archive of a directory (or a series of files).

You would use it like so…

  1. cd to root folder
  2. tar -cvzf name.tgz dir

This makes a tar archive of dir.

  1. tar -xvf name.tgz

This will extract the archive  name.tgz wherever you are.

or
tar -xvf file.tar.gz -C /some/dir/

This will change  to /some/dir/ and extract file.tar.gz there.