Greetings, weary tech[no] traveler!
Breached databases are a common occurrence in this digital age we live in. Login credentials are leaked onto the internet all the time. Adobe, Snapchat, Dominos Pizza, are just a few of the countless companies and institutions who had their costumers account information stolen; including usernames, email addresses, and passwords (more like password hashes). At the beginning of 2015 many costumers of companies, such as Intuit (known for their Turbo Tax software) and the University of Oregon, became data breach victims. Most of the time they're rarely notified that their data has been compromised and available to anyone on the internet, for long periods of time. This is the polar opposite of good!
Despair not! There is website that will tell you if your email address was found in a leaked user credentials database. It's called haveibeenpwned.com. It's a pet project of a heavy weight champion in the world of web security, Troy Hunt. Just enter in an email address. The site will check it's database of breached sites and return it's results to you.
You're probably thinking "Wait a sec...I bet whoever is running this site is harvesting email addresses! Why should I believe the Tech[no] Survival Guide?". You don't have to believe me. Check out the details for yourself.
Not only does haveibeenpwned check single email address through it's web interface, it also provides a handy API. So, you can write your own programs that use this awesome service! Which is what I did. I wrote a handy python script, called checkpwnedemails, that is capable of checking a single email address or multiple email addresses right from your command line interface. Also, it can write the results to a (tab delimited) text file. Which can be useful for reports, or storing in a database for later analysis. It's free (as in, free beer) and open source. You can get a copy of it from here.
To use checkpwnedemails, you need to have a python 2.7 (or greater) installed on your computer.
To check a single email, type the following command:
python checkpwnedemails.py -s <email_address>
To limit the results to breached websites:
python checkpwnedemails.py -b -s <email_address>
To limit the results to login credentials found in paste sites (such as pastebin):
python checkpwnedemails.py -t -s <email_address>
To check multiple email addresses, provide a text file listing the email addresses you wish to check (one address per line):
python checkpwnedemails.py -i <list_of_email_addresses>
If you want the results to only contain email addresses that were pwned, pass the -p option, like this:
python checkpwnedemails.py -p -i <list_of_email_addresses>
Of course, the -b and -t tags can be used as well.
If you want to print the results to a (tab delimited) text file:
python checkpwnedemails.py -i <list_of_email_addresses> -o <name_of_output_file>
If you did not provide the -b or -t option, then two files (one for breaches and one for pastes) will be created by default.
If you find that your email address(es) was in haveibeenpwned's database, it would be in your best interest to immediately change the password of the corresponding account. As a matter of fact if you (or someone you know) are one of those people who use the same password for everything, then change all your passwords (and use a different password for each account!).
Friday, February 20, 2015
Sunday, February 8, 2015
Adding yourself back into the sudo group on Raspberry Pi
Greetings, weary tech[no] traveler!
Have you ever lock yourself out of the sudo group, on your Raspberry Pi, by accident...and your user was the only one that had sudo permissions? It happened to me once. I was worried that I would need to reformat my SD card, reinstall Raspbian, and reconfigure my Raspberry Pi all over again. However, that is completely unnecessary. Here's what you need to do:
Have you ever lock yourself out of the sudo group, on your Raspberry Pi, by accident...and your user was the only one that had sudo permissions? It happened to me once. I was worried that I would need to reformat my SD card, reinstall Raspbian, and reconfigure my Raspberry Pi all over again. However, that is completely unnecessary. Here's what you need to do:
- Power down your Raspberry Pi.
- Remove the SD card and insert it into your PC.
- Change directory to your mounted SD card. Since I am using OSX:
cd /Volumes/boot/ - Open the file named "cmdline.txt" with your favorite text editor.
- Add the following text to the end of the existing text. It will drop you into a root shell upon reboot:init=/bin/shMake sure it is all one line!
- Save "cmdline.txt" and eject the SD card from the PC.
- Put the SD card back into the Raspberry Pi.
- Connect a USB keyboard and monitor to the Raspberry Pi.
- Power on the Raspberry Pi.
- Once you see a flashing cursor, remount the filesystem as read-write, add your user back into the sudo group, and shutdown the Raspberry Pi. To do that, enter the following commands at the prompt:
mount -o remount,rw /
usermod -a -G sudo <username>
shutdown -P now - Remove the SD card, reinsert it into your PC, and open the "cmdline.txt" file again with a text editor.
- Delete the “init=/bin/sh” text you added in step 5.
- Save "cmdline.txt" and eject the SD card from the PC. One last time.
- Put the SD card back into your Raspberry Pi, reboot, and rejoice in your reclaimed sudoer privileges!
Sunday, August 17, 2014
Fixing up Raspberry Pi with apt-get update woes.
Greetings, weary tech[no] traveler!
Lately, I've been having some trouble updating the software on my Raspberry Pi (running Raspbian) via 'apt-get update'. Every time I would run:
sudo apt-get update
I would get the following output:
Hit http://archive.raspberrypi.org wheezy Release.gpg
Hit http://mirrordirector.raspbian.org wheezy Release.gpg
Hit http://archive.raspberrypi.org wheezy Release
Hit http://mirrordirector.raspbian.org wheezy Release
Hit http://archive.raspberrypi.org wheezy/main armhf Packages
Ign http://archive.raspberrypi.org wheezy/main Translation-en
Hit http://raspberrypi.collabora.com wheezy Release.gpg
Hit http://raspberrypi.collabora.com wheezy Release
Hit http://raspberrypi.collabora.com wheezy/rpi armhf Packages
Ign http://raspberrypi.collabora.com wheezy/rpi Translation-en
Get:1 http://mirrordirector.raspbian.org wheezy/main armhf Packages [6891 kB]
Hit http://mirrordirector.raspbian.org wheezy/contrib armhf Packages
Hit http://mirrordirector.raspbian.org wheezy/non-free armhf Packages
Hit http://mirrordirector.raspbian.org wheezy/rpi armhf Packages
Ign http://mirrordirector.raspbian.org wheezy/contrib Translation-en
Ign http://mirrordirector.raspbian.org wheezy/main Translation-en
Ign http://mirrordirector.raspbian.org wheezy/non-free Translation-en
Ign http://mirrordirector.raspbian.org wheezy/rpi Translation-en
100% [1 Packages xz 0 B]
And it would just hang there. Until the SSH connection would time out.
It is important for me to successfully run updates on my Raspberry Pi. If you're running something like Apache or a MySQL server you've got to be able to patch them. Also, I have a healthy case of paranoia when it comes to software updates and information security. Anyway...
It turned out I was running an older version of the Raspberry Pi firmware, which was impeding my ability to successfully run apt-get update && apt-get upgrade.
I'm sure I'm not the only one who had this problem. Now that I've fixed this problem for myself, I thought I'd show you how to fix it yourself.
Lately, I've been having some trouble updating the software on my Raspberry Pi (running Raspbian) via 'apt-get update'. Every time I would run:
sudo apt-get update
I would get the following output:
Hit http://archive.raspberrypi.org wheezy Release.gpg
Hit http://mirrordirector.raspbian.org wheezy Release.gpg
Hit http://archive.raspberrypi.org wheezy Release
Hit http://mirrordirector.raspbian.org wheezy Release
Hit http://archive.raspberrypi.org wheezy/main armhf Packages
Ign http://archive.raspberrypi.org wheezy/main Translation-en
Hit http://raspberrypi.collabora.com wheezy Release.gpg
Hit http://raspberrypi.collabora.com wheezy Release
Hit http://raspberrypi.collabora.com wheezy/rpi armhf Packages
Ign http://raspberrypi.collabora.com wheezy/rpi Translation-en
Get:1 http://mirrordirector.raspbian.org wheezy/main armhf Packages [6891 kB]
Hit http://mirrordirector.raspbian.org wheezy/contrib armhf Packages
Hit http://mirrordirector.raspbian.org wheezy/non-free armhf Packages
Hit http://mirrordirector.raspbian.org wheezy/rpi armhf Packages
Ign http://mirrordirector.raspbian.org wheezy/contrib Translation-en
Ign http://mirrordirector.raspbian.org wheezy/main Translation-en
Ign http://mirrordirector.raspbian.org wheezy/non-free Translation-en
Ign http://mirrordirector.raspbian.org wheezy/rpi Translation-en
100% [1 Packages xz 0 B]
And it would just hang there. Until the SSH connection would time out.
It is important for me to successfully run updates on my Raspberry Pi. If you're running something like Apache or a MySQL server you've got to be able to patch them. Also, I have a healthy case of paranoia when it comes to software updates and information security. Anyway...
It turned out I was running an older version of the Raspberry Pi firmware, which was impeding my ability to successfully run apt-get update && apt-get upgrade.
I'm sure I'm not the only one who had this problem. Now that I've fixed this problem for myself, I thought I'd show you how to fix it yourself.
- First, make sure your Raspberry Pi has a solid connection to the internet.
- Log in.
- Update the Raspberry Pi firmware:
sudo rpi-update
If rpi-update terminates with the following (or similar) error:
*** Relaunching after update
*** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
*** We're running for the first time
*** Backing up files (this will take a few minutes)
*** Backing up firmware
*** Backing up modules 3.12.20+
cp: cannot stat `//lib/modules/3.12.20+': No such file or directory
Then create a directory called in 3.12.20+ in the directory /lib/modules/:
sudo mkdir /lib/modules/3.12.20+and then run sudo rpi-update again. - This will take about 10 minutes, so go for a walk, grab a beer, etc.
- If no errors appeared, your firmware was successfully updated. Reboot your Raspberry Pi to activate the new firmware:
sudo reboot - Once the Raspberry Pi has rebooted, log in, and run your updates:
sudo apt-get update && sudo apt-get upgrade
Tuesday, August 12, 2014
Ubuntu 14 and Apache and MoinMoin! Oh my! (Part 2)
Greetings, weary tech[no] traveler!
Welcome to Part 2 of Ubuntu 14 and Apache and MoinMoin! Oh my!
Suppose your wiki contains sensitive data and utilizes the user authentication features MoinMoin. It would be a good idea to secure it from eavesdropping creeps using man-in-the-middle attacks, wouldn't it? We should configure our wiki's apache config file to use https, along with SSL certificates, to encrypt all of the traffic to and from our wiki site. That way, anyone who's packet sniffing on your network (or the network your site is hosted from) won't be able to make any sense of what they are recording.
Once you have generated your SSL certificate and private key move your SSL certificate to /etc/ssl/certs/ and your private key to /etc/ssl/private/:
sudo mv humboldtwiki_example_com_cert.cer /etc/ssl/certs
sudo mv myprivateSSLkey.key /etc/ssl/private
NOTE: NEVER give your private SSL key to anyone. If you give a private key to someone, that someone now has the key to your castle, rendering any encryption useless.
After you have moved your certificate and private key, enable Apache's SSL module:
sudo a2enmod ssl
Next, make sure the directory /etc/ssl/private has the following permissions:
drwx--x--- 2 root ssl-cert 4096 private/
And the contents have permissions and group settings like this:
-rw-r----- 1 root ssl-cert 1704 myprivateSSLkey.key
-rw-r----- 1 root ssl-cert 1704 ssl-cert-snakeoil.key
If the new private key has different permissions, change them to match the ones above like this:
sudo chgrp ssl-cert myprivateSSLkey
sudo chmod 640 myprivateSSLkey.key
As a matter of fact, all of the private keys in this directory should have the same permissions described above.
Modify, the Apache config file (in our case, humboldtwiki.conf) to your wiki site like this:
# create some wsgi daemons - use these parameters for a simple setup
WSGIDaemonProcess moin user=www-data group=www-data processes=5 threads=10 maximum-requests=1000 umask=0007 display-name=wsgi-moin
# use the daemons we defined above to process requests!
WSGIProcessGroup moin
<VirtualHost humboldtwiki.example.com:80>
ServerName humboldtwiki.example.com
ServerAdmin webmaster@example.com
Redirect 301 / https://humboldtwiki.example.com
CustomLog /var/log/apache2/humboldtwiki-80-access.log combined
ErrorLog /var/log/apache2/humboldtwiki-80-error.log
</VirtualHost>
<VirtualHost humboldtwiki.example.com:443>
ServerName humboldtwiki.example.com
ServerAdmin webmaster@example.com
WSGIPassAuthorization On
SSLEngine on
SSLCertificateFile /etc/ssl/certs/humboldtwiki_example_com_cert.cer
SSLCertificateKeyFile /etc/ssl/private/myprivateSSLkey.key
DocumentRoot /usr/share/moin/humboldtwiki
WSGIScriptAlias / /usr/share/moin/humboldtwiki/moin.wsgi
<Directory />
Options FollowSymLinks
AllowOverride all
Allow from All
Require all denied
</Directory>
<Directory /usr/share/moin/humboldtwiki>
AllowOverride All
Allow From All
Require all granted
</Directory>
ErrorLog /var/log/apache2/humboldtwiki-error.log
LogLevel warn
CustomLog /var/log/apache2/humboldtwiki-access.log combined
</VirtualHost>
What this Apache config does, is that it forces all users to connect to the wiki site using https. Anytime a user navigates to the url, http://humboldtwiki.example.com, their web browser will be redirected to https://humboldtwiki.example.com.
Now, let's restart Apache so that our changes will take effect:
sudo service apache2 restart
There you have it! You've now protected your wiki site, and your users, from the classic man-in-the-middle attack.
Welcome to Part 2 of Ubuntu 14 and Apache and MoinMoin! Oh my!
Suppose your wiki contains sensitive data and utilizes the user authentication features MoinMoin. It would be a good idea to secure it from eavesdropping creeps using man-in-the-middle attacks, wouldn't it? We should configure our wiki's apache config file to use https, along with SSL certificates, to encrypt all of the traffic to and from our wiki site. That way, anyone who's packet sniffing on your network (or the network your site is hosted from) won't be able to make any sense of what they are recording.
Once you have generated your SSL certificate and private key move your SSL certificate to /etc/ssl/certs/ and your private key to /etc/ssl/private/:
sudo mv humboldtwiki_example_com_cert.cer /etc/ssl/certs
sudo mv myprivateSSLkey.key /etc/ssl/private
NOTE: NEVER give your private SSL key to anyone. If you give a private key to someone, that someone now has the key to your castle, rendering any encryption useless.
After you have moved your certificate and private key, enable Apache's SSL module:
sudo a2enmod ssl
Next, make sure the directory /etc/ssl/private has the following permissions:
drwx--x--- 2 root ssl-cert 4096 private/
And the contents have permissions and group settings like this:
-rw-r----- 1 root ssl-cert 1704 myprivateSSLkey.key
-rw-r----- 1 root ssl-cert 1704 ssl-cert-snakeoil.key
If the new private key has different permissions, change them to match the ones above like this:
sudo chgrp ssl-cert myprivateSSLkey
sudo chmod 640 myprivateSSLkey.key
As a matter of fact, all of the private keys in this directory should have the same permissions described above.
Modify, the Apache config file (in our case, humboldtwiki.conf) to your wiki site like this:
# create some wsgi daemons - use these parameters for a simple setup
WSGIDaemonProcess moin user=www-data group=www-data processes=5 threads=10 maximum-requests=1000 umask=0007 display-name=wsgi-moin
# use the daemons we defined above to process requests!
WSGIProcessGroup moin
<VirtualHost humboldtwiki.example.com:80>
ServerName humboldtwiki.example.com
ServerAdmin webmaster@example.com
Redirect 301 / https://humboldtwiki.example.com
CustomLog /var/log/apache2/humboldtwiki-80-access.log combined
ErrorLog /var/log/apache2/humboldtwiki-80-error.log
</VirtualHost>
<VirtualHost humboldtwiki.example.com:443>
ServerName humboldtwiki.example.com
ServerAdmin webmaster@example.com
WSGIPassAuthorization On
SSLEngine on
SSLCertificateFile /etc/ssl/certs/humboldtwiki_example_com_cert.cer
SSLCertificateKeyFile /etc/ssl/private/myprivateSSLkey.key
DocumentRoot /usr/share/moin/humboldtwiki
WSGIScriptAlias / /usr/share/moin/humboldtwiki/moin.wsgi
<Directory />
Options FollowSymLinks
AllowOverride all
Allow from All
Require all denied
</Directory>
<Directory /usr/share/moin/humboldtwiki>
AllowOverride All
Allow From All
Require all granted
</Directory>
ErrorLog /var/log/apache2/humboldtwiki-error.log
LogLevel warn
CustomLog /var/log/apache2/humboldtwiki-access.log combined
</VirtualHost>
What this Apache config does, is that it forces all users to connect to the wiki site using https. Anytime a user navigates to the url, http://humboldtwiki.example.com, their web browser will be redirected to https://humboldtwiki.example.com.
Now, let's restart Apache so that our changes will take effect:
sudo service apache2 restart
There you have it! You've now protected your wiki site, and your users, from the classic man-in-the-middle attack.
Monday, August 11, 2014
Ubuntu 14 and Apache and MoinMoin! Oh my! (Part 1)
Greetings, weary tech[no] traveler!
Sure has been a while since the last post, hasn't it? I could go on about why I haven't posted in a while, but why? You're here to find out how to serve up a wiki, right?
Recently I had to set up and configure and a wiki site, complete with https and SSL certificates. For this task, I decided to use what I called the MUA (MoinMoin, Ubuntu, Apache) stack. We're all familiar with the greatness of Ubuntu and Apache, but out of all the wiki solutions that are available why did I choose MoinMoin? MoinMoin is a free and open source wiki solution, that is easy to install, configure, and use. Plus, it's written in python. As a python fanatic, I have a bias for anything python related.
So, let's get down to it! Log into your shinny new Ubuntu 14.04 server and install Apache, as well as MoinMoin and the mod_wsgi apache module:
sudo apt-get install apache2 python-moinmoin libapache2-mod-wsgi -y
Once Apache, mod_wsgi, and MoinMoin are finished downloading and installing, enable mod_wsgi by running the following command:
sudo a2enmod wsgi
Next, let's configure MoinMoin. You can name your wiki site anything you want, but for the sake of example let's call the wiki in this example, humboldt. In the interest of modularity, let's configure MoinMoin so that we can serve more than one wiki later on down the road. At the command line, create a directory for our wiki site, and copy our wiki config and wsgi config files:
sudo mkdir /usr/share/moin/humboldt
sudo cp /usr/share/moin/config/wikiconfig.py /usr/share/moin/humboldt
sudo cp /usr/share/moin/server/moin.wsgi /usr/share/moin/humboldt
Next, we'll configure our wsgi file for humboldt. Open /usr/share/moin/humboldt/moin.wsgi in a text editor of your choice. Once opened change the following line:
sys.path.insert(0, '/etc/moin')
to:
sys.path.insert(0, '/usr/share/moin/humboldt')
Now, let's configure our wiki config file, wikiconfig.py. This is the file that you will edit to make configurations that are specific to humboldt only. For now, let's change the site name and interwiki name for humboldt.
Using vim, I made the following changes to wikiconfig.py:
sitename = u'Humboldt Wiki'
interwikiname = u'HumboldtWiki'
There are lots of ways to configure MoinMoin. However, the details of wikiconfig.py is not within the scope of this post since I'm only going to cover how to install MoinMoin as well as serve it with Apache, using mod_wsgi. I'll talk more about that in a future post.
We need to add our configuration of humboldt to MoinMoin. First, we must create a config file specifically for humboldt. To do that:
cd /etc/moin
sudo cp mywiki.py humboldtwiki.py
Then edit humboldtwiki.py. Change it so that the class Config looks something like this:
class Config(FarmConfig):
# basic options (you normally need to change these)
sitename = u'HumboldtWiki'
interwikiname = u'HumboldtWiki'
# name of entry page / front page [Unicode], choose one of those:
# a) if most wiki content is in a single language
#page_front_page = u"MyStartingPage"
# b) if wiki content is maintained in many languages
page_front_page = u"FrontPage"
data_dir = '/usr/share/moin/humboldt/data'
data_underlay_dir = '/usr/share/moin/humboldt/underlay'
Save and close the humboldtwiki.py. Then within the same directory, open and edit the wikis variable, in file the farmconfig.py, to look like this:
wikis = [
("humboldtwiki", r"^http://humboldtwiki\.example\.com/.*$"),
]
Adding our wiki to the wikis variable in this fashion will allow us to add another wiki instance in the future (if we so choose), with little effort. It never hurts to plan ahead!
Save and close the farmconfig.py file.
Now that we've done the initial setup and configuration of our MoinMoin wiki site, let's move onto creating and configuring our apache config file for it. At the command line:
cd /etc/apache2/sites-available
sudo vim humboldtwiki.conf
Again, you don't have to use vim. Just use whatever text editor you like.
In your new, blank, apache config file add the following:
# create some wsgi daemons - use these parameters for a simple setup
WSGIDaemonProcess moin user=www-data group=www-data processes=5 threads=10 maximum-requests=1000 umask=0007 display-name=wsgi-moin
# use the daemons we defined above to process requests!
WSGIProcessGroup moin
<VirtualHost humboldtwiki.example.com:80>
ServerName humboldtwiki.example.com
ServerAdmin webmaster@example.com
WSGIPassAuthorization On
DocumentRoot /usr/share/moin/humboldtwiki
WSGIScriptAlias / /usr/share/moin/humboldtwiki/moin.wsgi
<Directory />
Options FollowSymLinks
AllowOverride all
Allow from All
Require all denied
</Directory>
<Directory /usr/share/moin/humboldtwiki>
AllowOverride All
Allow From All
Require all granted
</Directory>
ErrorLog /var/log/apache2/humboldtwiki-error.log
LogLevel warn
CustomLog /var/log/apache2/humboldtwiki-access.log combined
</VirtualHost>
We're almost done. Now we need to create a symlink in Apache's "sites-enabled" directory, to the config file we just created. After that, we'll need to restart Apache. At the shell prompt, enter the following commands:
cd /etc/apache2/sites-enabled
sudo ln -s ../sites-available/humboldtwiki.conf .
sudo service apache2 restart
Voilà! Now you're serving up a MoinMoin wiki site, using Apache and mod_wsgi!
However, if you plan on keeping data sensitive wiki pages, you'll want to force https on the users. If you're interested in using https with MoinMoin, check out Part 2 of Ubuntu 14 and Apache and MoinMoin! Oh my!
Sure has been a while since the last post, hasn't it? I could go on about why I haven't posted in a while, but why? You're here to find out how to serve up a wiki, right?
Recently I had to set up and configure and a wiki site, complete with https and SSL certificates. For this task, I decided to use what I called the MUA (MoinMoin, Ubuntu, Apache) stack. We're all familiar with the greatness of Ubuntu and Apache, but out of all the wiki solutions that are available why did I choose MoinMoin? MoinMoin is a free and open source wiki solution, that is easy to install, configure, and use. Plus, it's written in python. As a python fanatic, I have a bias for anything python related.
So, let's get down to it! Log into your shinny new Ubuntu 14.04 server and install Apache, as well as MoinMoin and the mod_wsgi apache module:
sudo apt-get install apache2 python-moinmoin libapache2-mod-wsgi -y
Once Apache, mod_wsgi, and MoinMoin are finished downloading and installing, enable mod_wsgi by running the following command:
sudo a2enmod wsgi
Next, let's configure MoinMoin. You can name your wiki site anything you want, but for the sake of example let's call the wiki in this example, humboldt. In the interest of modularity, let's configure MoinMoin so that we can serve more than one wiki later on down the road. At the command line, create a directory for our wiki site, and copy our wiki config and wsgi config files:
sudo mkdir /usr/share/moin/humboldt
sudo cp /usr/share/moin/config/wikiconfig.py /usr/share/moin/humboldt
sudo cp /usr/share/moin/server/moin.wsgi /usr/share/moin/humboldt
Next, we'll configure our wsgi file for humboldt. Open /usr/share/moin/humboldt/moin.wsgi in a text editor of your choice. Once opened change the following line:
sys.path.insert(0, '/etc/moin')
to:
sys.path.insert(0, '/usr/share/moin/humboldt')
Now, let's configure our wiki config file, wikiconfig.py. This is the file that you will edit to make configurations that are specific to humboldt only. For now, let's change the site name and interwiki name for humboldt.
Using vim, I made the following changes to wikiconfig.py:
sitename = u'Humboldt Wiki'
interwikiname = u'HumboldtWiki'
There are lots of ways to configure MoinMoin. However, the details of wikiconfig.py is not within the scope of this post since I'm only going to cover how to install MoinMoin as well as serve it with Apache, using mod_wsgi. I'll talk more about that in a future post.
We need to add our configuration of humboldt to MoinMoin. First, we must create a config file specifically for humboldt. To do that:
cd /etc/moin
sudo cp mywiki.py humboldtwiki.py
Then edit humboldtwiki.py. Change it so that the class Config looks something like this:
class Config(FarmConfig):
# basic options (you normally need to change these)
sitename = u'HumboldtWiki'
interwikiname = u'HumboldtWiki'
# name of entry page / front page [Unicode], choose one of those:
# a) if most wiki content is in a single language
#page_front_page = u"MyStartingPage"
# b) if wiki content is maintained in many languages
page_front_page = u"FrontPage"
data_dir = '/usr/share/moin/humboldt/data'
data_underlay_dir = '/usr/share/moin/humboldt/underlay'
Save and close the humboldtwiki.py. Then within the same directory, open and edit the wikis variable, in file the farmconfig.py, to look like this:
wikis = [
("humboldtwiki", r"^http://humboldtwiki\.example\.com/.*$"),
]
Adding our wiki to the wikis variable in this fashion will allow us to add another wiki instance in the future (if we so choose), with little effort. It never hurts to plan ahead!
Save and close the farmconfig.py file.
Now that we've done the initial setup and configuration of our MoinMoin wiki site, let's move onto creating and configuring our apache config file for it. At the command line:
cd /etc/apache2/sites-available
sudo vim humboldtwiki.conf
Again, you don't have to use vim. Just use whatever text editor you like.
In your new, blank, apache config file add the following:
# create some wsgi daemons - use these parameters for a simple setup
WSGIDaemonProcess moin user=www-data group=www-data processes=5 threads=10 maximum-requests=1000 umask=0007 display-name=wsgi-moin
# use the daemons we defined above to process requests!
WSGIProcessGroup moin
<VirtualHost humboldtwiki.example.com:80>
ServerName humboldtwiki.example.com
ServerAdmin webmaster@example.com
WSGIPassAuthorization On
DocumentRoot /usr/share/moin/humboldtwiki
WSGIScriptAlias / /usr/share/moin/humboldtwiki/moin.wsgi
<Directory />
Options FollowSymLinks
AllowOverride all
Allow from All
Require all denied
</Directory>
<Directory /usr/share/moin/humboldtwiki>
AllowOverride All
Allow From All
Require all granted
</Directory>
ErrorLog /var/log/apache2/humboldtwiki-error.log
LogLevel warn
CustomLog /var/log/apache2/humboldtwiki-access.log combined
</VirtualHost>
We're almost done. Now we need to create a symlink in Apache's "sites-enabled" directory, to the config file we just created. After that, we'll need to restart Apache. At the shell prompt, enter the following commands:
cd /etc/apache2/sites-enabled
sudo ln -s ../sites-available/humboldtwiki.conf .
sudo service apache2 restart
Voilà! Now you're serving up a MoinMoin wiki site, using Apache and mod_wsgi!
However, if you plan on keeping data sensitive wiki pages, you'll want to force https on the users. If you're interested in using https with MoinMoin, check out Part 2 of Ubuntu 14 and Apache and MoinMoin! Oh my!
Tuesday, January 7, 2014
Fixing NIS Client/AutoFS Login Permission Error
Greetings, weary tech[no] traveler!
So...you've decided to make that shinny, new Ubuntu 12.04 server of yours into an NIS client. You've gone through all the necessary steps to install and set up NIS, AutoFS, and NFS. Yet for some reason (which will be made obvious soon), neither you nor anyone else with NIS credentials can:
Could not chdir to home directory /home/username: Permission denied
-bash: /home/username/.bash_profile: Permission denied
Permission denied?! What gives, brah?
Let's check the permissions of all the home directories. At the command line, run the following command:
ls -l /home
You will get output that will look similar to this:
drwx--S--- 15 username username 4096 Dec 31 15:04 username/
:
:
:
Apparently, the permissions on the home directory are restrictive such that there are no read, write, or execute bits for group (g+rwx). Since username (in your case might be something different) is most likely not a valid NIS group (depending on how you set up your NIS groups), there's no way you'll be able to access your home directory; let alone auto-mount it.
Let's check and compare one other thing; the User IDs (UID) of username on the NIS server we are trying to authenticate with and on our troublesome NIS client. Alternatively, if you do not have access to the NIS server, you can check the UID of username on another NIS client that does work. At the command line of both machines, run the following command:
getent passwd username
The output from our troublesome NIS client will look similar to this:
username:x:1000:1000:username,,,:/home/username:/bin/bash
The output from the same command, ran on our NIS server (or working NIS client), will look similar to this:
username:x:34528:1000:username,,,:/home/username:/bin/bash
Notice how the UIDs are different. The UID, of username, on the NIS server is (in this case) 34528. Whereas on our NIS client, the UID is 1000. The UIDs of username do not match and they must be changed so that they do. Plus, the group called username, which is local to our troublesome NIS client must be deleted as well. Otherwise, the local group (username) will be used instead of the appropriate group that is provided by our NIS server.
Before we start making changes to important files, let's back them up first. Just in case!
sudo cp /etc/passwd /etc/passwd_BACKUP
sudo cp /etc/group /etc/group_BACKUP
Now, let's fix this problem.
So...you've decided to make that shinny, new Ubuntu 12.04 server of yours into an NIS client. You've gone through all the necessary steps to install and set up NIS, AutoFS, and NFS. Yet for some reason (which will be made obvious soon), neither you nor anyone else with NIS credentials can:
- Edit, delete, create, or copy any files they owned before NIS was set up.
- Get their home directory (for example: /home/username) auto-mounted.
Could not chdir to home directory /home/username: Permission denied
-bash: /home/username/.bash_profile: Permission denied
Permission denied?! What gives, brah?
Let's check the permissions of all the home directories. At the command line, run the following command:
ls -l /home
You will get output that will look similar to this:
drwx--S--- 15 username username 4096 Dec 31 15:04 username/
:
:
:
Apparently, the permissions on the home directory are restrictive such that there are no read, write, or execute bits for group (g+rwx). Since username (in your case might be something different) is most likely not a valid NIS group (depending on how you set up your NIS groups), there's no way you'll be able to access your home directory; let alone auto-mount it.
Let's check and compare one other thing; the User IDs (UID) of username on the NIS server we are trying to authenticate with and on our troublesome NIS client. Alternatively, if you do not have access to the NIS server, you can check the UID of username on another NIS client that does work. At the command line of both machines, run the following command:
getent passwd username
The output from our troublesome NIS client will look similar to this:
username:x:1000:1000:username,,,:/home/username:/bin/bash
The output from the same command, ran on our NIS server (or working NIS client), will look similar to this:
username:x:34528:1000:username,,,:/home/username:/bin/bash
Notice how the UIDs are different. The UID, of username, on the NIS server is (in this case) 34528. Whereas on our NIS client, the UID is 1000. The UIDs of username do not match and they must be changed so that they do. Plus, the group called username, which is local to our troublesome NIS client must be deleted as well. Otherwise, the local group (username) will be used instead of the appropriate group that is provided by our NIS server.
Before we start making changes to important files, let's back them up first. Just in case!
sudo cp /etc/passwd /etc/passwd_BACKUP
sudo cp /etc/group /etc/group_BACKUP
Now, let's fix this problem.
- sudo vim /etc/passwd [Personally, I like to use vim. However, you can user whatever text editor your like.]
- Locate the line for the username in question. In this case, it's username.
- Edit the UID of username so that it matches the UID of username from our NIS server. In this case, the UID of 1000 should be changed to 34528.
- Save and exit your text editor.
- Back at the command line, edit /etc/group: sudo vim /etc/group
- Locate the line for the username group. It should look like this: username:x:1000:
- Delete this line.
- Save and exit your text editor.
- Reboot your NIS client: sudo shutdown -r now
Thursday, December 19, 2013
Update the locate database in OS X Mavericks (10.9)
Greetings, weary tech[no] traveler!
A great command to help find files via the Unix command line is "locate". Not only is it simple to use:
locate <name of file> (without the '<' and '>' characters)
but it is quick to return results too.
To do this, the "locate" command relies on a local database to index and, furthermore, return results to you quickly. Therefore, this local database needs to be updated periodically.
Unlike most other Unix based operating systems, simply running "updatedb" in the OS X (10.9 mavericks) terminal won't work. So how do we update the locate database for OS X Mavericks (OS 10.9)? Like this:
1. Launch terminal
2. Change your user session to root:
sudo su - (then type your password)
3. Go to the directory /usr/libexec/
cd /usr/libexec/
4. Run the following command to update the locate database:
./locate.updatedb
After a minute (or 5) your locate database will be updated, and you can continue to use your command line.
It should be noted that this will only work for those who have sudo privileges to their machine. For good practice, remember to log out of root when you're done (by typing 'exit' at the command line).
A great command to help find files via the Unix command line is "locate". Not only is it simple to use:
locate <name of file> (without the '<' and '>' characters)
but it is quick to return results too.
To do this, the "locate" command relies on a local database to index and, furthermore, return results to you quickly. Therefore, this local database needs to be updated periodically.
Unlike most other Unix based operating systems, simply running "updatedb" in the OS X (10.9 mavericks) terminal won't work. So how do we update the locate database for OS X Mavericks (OS 10.9)? Like this:
1. Launch terminal
2. Change your user session to root:
sudo su - (then type your password)
3. Go to the directory /usr/libexec/
cd /usr/libexec/
4. Run the following command to update the locate database:
./locate.updatedb
After a minute (or 5) your locate database will be updated, and you can continue to use your command line.
It should be noted that this will only work for those who have sudo privileges to their machine. For good practice, remember to log out of root when you're done (by typing 'exit' at the command line).
Subscribe to:
Posts (Atom)