Install MySQL on Ubuntu 14.04.3 When Changing Root Password Errors

I found this for some reason on my Digital Ocean droplet when trying to install mysql. The server would be placed in this broken state all due to the root password of the server failing. Fortunately some trial and error found a solution. I followed along with this tutorial for the most part.

https://www.digitalocean.com/community/tutorials/how-to-install-linux-apache-mysql-php-lamp-stack-on-ubuntu-14-04

I also noticed when the installation did complete it said MySQL was running on a 14.04.1 server, which is not true...I do not know why this appears but I suspect maybe there is some kind of unknown permissions bug with MySQL at the moment and 14.04.3

The Fix

Basically its the usual sudo apt-get install mysql-server as given in the link above except when it does prompt for the root password leave it blank...DO NOTHING. let the software install itself.

Then we hit the setup scripts. And these are your saviours

After instalation completes. Run this guy:

sudo mysql_install_db  

Then run this guy:

sudo mysql_secure_installation  

Within this second script you will be prompted with the option to reset the root password. At THIS point change the root password to what you would like. And you will have no errors

Side Notes

I don't know if it actually have any effect whatsoever but I also have mongodb running on the same server. So I also had it turned off while this whole installation process occurred in case it interfered. If you have issues still with the above and have mongo installed, try that aswell

sudo service mongod stop #turn off mongo  
sudo service mongod start #turn on mongo  

Setup A Basic Gateway Server on Linux

Sources


**Full Disclosure**

This was tested on Ubuntu 14.04.1, items referenced below will be relative to locations in Ubuntu 14.04.1. The setup though across Linux distros should be the same other then paths. I will update this posting with location paths as they become known to me

-UPDATE: Additional notes added for Fedora 22
-UPDATE: This his now been tested on Ubuntu Server 14.04.1, 14.04.3 and Fedora 22. Documentation is complete to allow full setups on either of the 3 systems


This setup is a basic setup of a Gateway server. Note that this is not a tutorial on how to actually secure or properly secure the gateway. The intention of this tutorial is simply to get it working. It will allow anything to go through and work. The idea of this tutorial is to cator to first-time setups and people who would like to just tinker around.

Terminology

For this tutorial we have 2 devices - the Gateway Host and the Internal Host. The Internal Host being the machine behind the Gateway Host and relies on it in order to filter/forward/network all of the Internal Hosts traffic to the outside world

Setup the Gateway Host

Assumingly your Gateway Host has 2 network cards or connections of some kind. This is needed so that traffic from your Internal Host will come in one card of the Gateway Host and then sent out the other of the Gateway Host.

1. Configure Network Cards

Enter the following command:

ifconfig -a  

This will display all enabled and disabled cards. Find the card that will service your Internal Host. This will likely have a name like eth0 or eth1 on Ubuntu.

Then execute the following command. eth0 with the name of the card that services the Internal Host. Note also that as a newly enabled card we have statically assigned it an IP address 192.168.10.1 so that it can be routed to by the Internal Host.

ifconfig eth0 192.168.10.1 up  

2. Enable Kernel Forwarding

Kernel forwarding needs to be enabled in order for data to travel between your different network cards. This can be done as so on Ubuntu:

sudo cp /etc/sysctl.conf /etc/sysctl.conf.bak && sudo nano /etc/sysctl.conf  

This will create a backup and open the sysctl.conf file in nano. Within this conf file, search for and uncomment the following line:

net.ipv4.ip_forward=1  

This will enable Kernel Forwarding. On Ubuntu you will need to restart your Gateway Host now for the change to take effect.

On Fedora, you can enable kernel forwarding in a similar way, or use the shortcut command:

echo "1" >/proc/sys/net/ipv4/ip_forward  

On fedora this may or may not need a restart

3. Setup NAT Routing

NAT Routing takes a few special commands using iptables. These commands will let everything back and forth through your Gateway Host so it is important to note that this will not secure your Internal Host whatsoever

Enter the following iptables commands in order:

# flush all rules in fulter and nat tables
iptables --flush  
iptables --table nat --flush  
iptables --delete-chain  
# delete all chains that are not in default filter and nat table
iptables --table nat --delete-chain

iptables --table nat --append POSTROUTING --out-interface eth0 -j MASQUERADE  
iptables --append FORWARD --in-interface eth1 -j ACCEPT  

Note again in the above commands to replace eth0 and eth1 with the appropriate card names. eth1 in the above example is the card serving the Internal Host and eth0 is connected to the outside network.

It is also important to note that the above rules only allows the Internal Host to have access to the outside world. If your Internal Host is offering services through the Gateway Host, additional rules will be needed.
To allow external machines to connect to the Internal Host add the following rules:

iptables --table nat -A PREROUTING -i eth0 -j DNAT --to-destination 192.168.10.2  
iptables --append FORWARD --in-interface eth0 -j ACCEPT #let everything through  

This will allow connections to come in to the Internal Host. For this example, our Internal Host's IP is 192.168.10.2 which you can see in the first rule above is the --to-destination meaning all traffic directed at the Gateway Host will be redirected to the Internal Host.
NOTE: With the second command listed above will allow everything to be redirected to the internal host. For a more secure procedure, replace this rule with more finite FORWARD table rules using iptables.

Setup the Internal Host

Now all we have to do is tell our Internal Host to resolve its IP's with our configured Gateway Host.

1. Configure Network Cards

Again execute the following command to determine the name of your network card that is connected to the Gateway Host

ifconfig -a  

Then execute the following command replacing eth0 with the name of the card connected to the Gateway Host

ifconfig eth0 192.168.10.2 up  

Note that the ip address we assigned here belongs to the subnet of our Gateway Host this is an important factor as our Gateway Host only knows how to route data from our 192.168.10.0 subnet to the outside world.

If your Internal Host only has a single network card, it may be already enabled and have an IP assigned to it. To change the IP to be part of the subnet run the following command

ifconfig eth0 down  

this will disable the network card. Use the command from earlier now to re-enable it and assign an IP.

If your Internal Host has multiple cards and some are connected to the internet, you will probably want to disable them so as to be able to test if your Gateway Host has been configured correctly. You can disable those cards with the ifconfig eth0 down command mentioned earlier, replacing the eth0 with the name of the card

2. Configure Routing

Now we want to route all traffic from our Internal Host to the Gateway Host. To do this we simply change the Internal Hosts default resolving IP to the Gateway Hosts IP. We do this with the following command:

route add default gw 192.168.10.1  

3. Check Nameserver Resolution Matches

Fedora 22

On Fedora you will need to make sure the Internal Host and the Gateway Host both have the same content written in the /etc/resolv.conf file. Most importantly you want to copy the contents of the Gateway Hosts resolve.conf into the Internal Hosts resolve.conf file. Otherwise you will have troubles making DNS calls from your Internal Host. A copy and paste and a possible reboot is all that is needed.

Ubuntu Server 14.04.1 - 14.04.3

On Ubuntu Server you will need to do the same as Fedora except Ubuntu automates the process more.
To view the nameservers on the Gateway Host enter the following command:

cat /etc/resolv.conf  

This will display the nameserver IP that needs to be copied to the Internal Host

To update the Internal Host's nameservers, run the following commands

cd /etc/resolvconf/resolv.conf.d  
sudo cp -p head head.orig  #create a backup copy  
sudo nano head  

In the now opened file type the following:

nameserver <ip-of-nameserver>  

Hit Ctrl+X to save and then type:

sudo resolvconf -u  

This will cause Ubuntu to reload its nameservers from the file that was edited.

Install MongoDB 3.0 on Fedora 22

Sources


There seems to be very little complete documentation on installing the latest versions of MongoDB on Fedora. My situation was specifically Fedora 22. I was able to get everything working fortunately after discovering a feed from someone else posting the question, and then some digging around the MongoDB documentation for start-up instructions. Oddly Mongo doesn't have anything specifically for Fedora, so I had to poke around and guess a bit with CentOS and RedHat instructions. Fortunately they are very much the same for the most part with Fedora

Add the Repository

This took a bit of mixing from the feed and the mongodb documentation. Taking from the feed doesn't end up completely adding the repository properly, so I found it worked better doing it the following way. cd to the repository directory in /etc/yum.repos.d/ and create a file called mongodb-org-3.0.repo. Then add the following in the file:

[mongodb-org-3.0]
name=MongoDB Repository  
baseurl=https://repo.mongodb.org/yum/redhat/$releasever/mongodb-org/3.0/x86_64/  
gpgcheck=0  
enabled=1  

Note that there is a variable $releasever in the above code snippet. From the feed for Fedora 22 the $releasever should be replaced with 7. Since this may eventually become obsolete though, I have left the variable in. Replace with the appropriate value is 7 is no longer appropriate

As a side, the main difference between the method of adding the repository described in the MongoDB documentation to the feed is the gpgcheck. From the snippet above and the MongoDB docs you can see it is set to false, as the code is not signed. The feed though adds the repository with the dnf helper command:

dnf config-manager --add-repo https://repo.mongodb.org/yum/redhat/$releasever/mongodb-org/3.0/x86_64/  

Which the config-manager default enabled the gpgcheck. Now you can side step this when you install with the --nogpgcheck parameter in the install call but I thought it was a bit messy for my liking.

Install Mongo

This is the easy part. Run and execute:

dnf install -y mongodb-org  

Start Mongo

This step tripped me up initially as Fedora, from my experience so far, names its services the same as the program name or the installed package. To start mongoDB though you need to execute the following command:

systemctl start mongod  

This command may take awhile as mongo does a first time load. Mongo will then have loaded. You can restart, stop and get the status of mongo with the following commands:

Stop Mongo

systemctl stop mongod  

Restart Mongo

systemctl restart mongod  

Get Mongo Status

systemctl status mongod  

Use Mongo

You can now interact with mongo locally through the mongo shell client like so:

mongo  

This will automatically log you in and load the test database. To configure Mongo further for external access and such, checkout the above links. The MongoDB documentation has good information on where to go. There is a specific issue with dealing with SELinux that the documentation says will interfere with that kind of setup

Hosting KeePass2 on IIS 8.5

Sources


Turns out hosting KeePass on IIS isn't too hard of a project. It only took me an age to realize I was searching in the wrong places. The last two links I sourced above are for setups in IIS 6 and IIS 7 and you can try them out if you would like..trust me I did and never got them working. Having IIS 8.5 on my system, I probably should have given the notion that chances were slim, but I blew my hours away anyway. Finally I figured out how to do it using WebDAV.

Now you should note WebDAV is quite vulnerable because it essentially allows any client to get your data, interact with it and put it back on your server. Basically it's hall pass for anyone wanting to put viruses on your server. With this in mind you should really make sure you have setup the appropriate securities on your server before enabling WebDAV. This tutorial isn't going to go over in depth any of these securities, it is intended to show how to get KeePass2 available over HTTP on IIS. I have left though some tips on where to go to start securing your website further for the interested reader.

Install WebDAV

The first link is a great source for instructions on this. It includes steps for IIS 7, 8 and 8.5 and for installing it on IIS on Windows 8 or in my case Windows Server. I'll list below the Windows Server instructions I followed from the site below:

  1. Click the Server Manager icon on the desktop
  2. In the Server Manager window, click the Manage menu, and then click Add Roles and Features.
  3. On the Before You Begin page, click Next.
  4. Select the Installation Type and then click Next.
  5. Select the Destination Server, and then click Next.
  6. On the Select Role Services page, expand Web Server (IIS), expand Web Server, expand Common HTTP Features, and then select WebDAV Publishing. Click Next
  7. On the Select Features page, click Next.
  8. Confirm the installation selection, and then click Install.
  9. On the Results page, verify that the installation succeeds, and then click Close.
  10. On the Confirm Installation Selections page, click Install.
  11. On the Results page, click Close.

Create/Setup IIS Site

Basically here create your IIS website as per usual.

  1. Open IIS, Select your server and right click the Sites folder and select Add Website
  2. Enter in a Site Name, a Physical Path to where the folder your site (and KeePass) file will be stored, enter a Host Name (your domain name) or enter "localhost" to make the site available only locally
  3. You should then be presented with the Home page of your newly created site. If not, click the Sites folder you right clicked on in step one and select your site you created from the list. In the IIS section, click the WebDAV Authoring Rules icon
  4. From this page you can set all WebDAV rules. If this is your first time installing WebDAV will likely be disabled, on the right Actions bar click the Enabled WebDAV button
  5. In the Actions bar aswell click Add Authoring Rules. This will present you options to set permissions on the site. Here you can set a number of securities about who is allowed in but for this tutorial all we need is to make sure the Allow access to section has the All content radio button selected, and at the bottom all 3 check boxes for Read, Source and Write in the Permissions section are checked. Then click OK
  6. Go back to the website Home page and select in the IIS section the MIME Types options. We need to add the KeePass file format as a known format to IIS, otherwise it will not be able to find the file
  7. On the MIME Types page select Add from the right side Actions menu.
  8. Enter the File name extension as .kdbx and set the MIME Type to application/kdbx
  9. Return back to the website Home page one last time and under the IIS section again select the Compression button. Here we are going to make sure IIS will serve dynamic objects (KeePass2 Files).
  10. On the Compression page make sure both Enable dynamic content compression and Enable static content compression are both checked.
  11. From the Sites drop down right click on your site, go to Manage Website and then click Restart. This will ensure all of our changes have been accounted for in our website

Add KeePass2 File

From here it is just a task of copying and pasting your KeePass2 file into the directory your website serves from. Once you have done that start up KeePass2 and do the following:

  1. Open KeePass2 and go to the menu select File and Open and then Open URL
  2. From here you can enter the domain URL to where your KeePass file is located. Note that within this domain must also include the name of your KeePass file as swell (eg. http://mydomain.com/keypass.kdbx). Press OK when you are finished
  3. Your KeePass file will then appear, enter your KeePass password and you are good to go!

KeePass2 Problems

If you end up unable to save your changes in your KeePass file, check the file permissions in the directory. Go to the folder location your KeePass file is stored and right click properties of your KeePass file. Try giving IIS Users priveleges to the file that you are unable to do. From one of the tutorials I sourced above I ran into issues where saving the file was failing because IIS Users did not have write access to my KeePass file.


Next Steps: Securing Everything

The Next things you should look at is securing your KeePass file. Granted that your KeePass2 file is already encrypted with all of its content, it is still not a good idea to leave your webserver wide open. Look into some of the following options for IIS to help lockdown your server and secure your KeePass file further:

  • Add Basic Authentication
    • You can enable and setup the credentials in IIS and then when you connect in KeePass the connection includes options to include these credentials
    • Note with Basic Auth on Windows you need to not only configure Basic Auth in IIS but also make sure your KeePass file's security permissions allow the Basic Auth user to have appropriate access to the file
  • Add SSL Certificate
    • Adding SSL is fairly simple and will encrypt the transmission of your Basic Auth credentials as well as the transfers of your KeePass file as its passed back and forth from you and the server between retrieval and saves.
    • Note if you use a self-signed certificate you will need to dig through KeePass' settings to make sure it ignores validating them, otherwise they will default be rejected as invalid

Configure Mailx (Mail) with Sendgrid

Sources:

After some trial and error and digging through the Sendgrid documentation I managed to successfuly find a way to send mail on linux using mailx. Sendgrid's documentation covers the use of the sendmail and ssmtp modules which require additional downloads. Granted both options are valid, I wanted to do it with mailx.

There is alot of documentation available on setting up mailx with gmail, and this is where I was able to start, crossed that over with sendgrids docs and about a dozen tries later I had mail sending through without errors (yes some configurations seemed to return me errors. I'll show you those aswell)


Configuring For Sendgrid

Basicaly the setup is very simple. On your linux system open up a terminal and type:

sudo nano /etc/mail.rc  

This will open up the config file for mailx. Scroll to the bottom of the config file and enter the following:

set smtp=smtp://smtp.sendgrid.net:587  
set [email protected]  
set smtp-auth=login  
set smtp-auth-user=mysendgridusername  
set smtp-auth-password=mysendgridpassword  

Replace mysendgridusername and mysendgridpassword with your sendgrid login credentials, and also set the from value to some useful email of some kind. The email you put in the set from value is what will default be used as to who the email is sent from. You can always override this when using the mail command and sendgrid accepts anyone as the recipient. You should note from Sendgrids's documentation that there is a maximum of 100 emails per connection. Also wouldn't be surprised if there is a max rate per hour also at that level.

After that save changes and your good to go. Interestingly enough mailx doesn't need anything restarted to work. Test out your configuration with some call like this:

mail -s "This is A Test Subject" [email protected]  

Hit enter and nothing will happen. This is where you can type the body of your email. When you are done hit enter. Type . and then hit enter again and the email should send.

Alternate Setup Attempts

Here I'm going to list some alternative ways to setup mailx that I was having it work in actualy sending mail, but mailx kept spitting out obscure errors after sending.

set smtp=smtp://smtp.sendgrid.net:587  
set [email protected]  
set ssl-verify=ignore  
set smtp-use-starttls  
set smtp-auth=login  
set smtp-auth-user=mysendgridusername  
set smtp-auth-password=mysendgridpassword  
set nss-config-dir=~/.mozilla/firefox/pblrihc5.default/  

This setup was the generally recommended setup for working with gmail. It uses a certificate from Firefox and explicitly enforces tls and along with that ignoring of the ssl certificates (what that means about the setup that worked I don't know. It wouldn't surprise me if it is actually sending in plain text). It sends everything successfully, the odd issue is after sending it returns an error that the peer's certificate is invalid.