Thursday, 28 March 2013

SharePoint 2013 Site Closure

I am working on SharePoint Server 2013 and just learnt about Site Closure or Closing a Site. What a great addition to the site management. This new feature allows an administrator to define a Site Policy to close or delete sites on a schedule.

To configure Site Closure you first have to make a Site Policy in the top level site settings under Site Collection Administration.

In the Site Policies page you can click create to make a Site Policy. When you create a Site Policy you have these options available to you.

The first radio button selection, "Do not close or delete site automatically", is purely so you can have the Site Collection be read only when it is closed.
If you select the second radio button "Delete sites automatically" you get more options.

As you can see, the site can be deleted automatically on a schedule based on either the Site closed date, or the Site created date.
If you choose the last radio button, "Close and delete sites automatically", you get one more schedule option available to you.

Now the site can be closed on schedule and deleted on schedule.

Once one or more Site Policies have been created you apply the policies to the existing sites using the Site Closure and Deletion link on the Site Settings page under Site Administration.

On the Site Closure and Deletion page you can close the site based on the policy you select at the bottom of the page.   To delete the site manually you need to go back to Site Setting and click Delete This Site under Site Actions.

So as you can see, it is a simple feature but enables the SharePoint administrators far greater control over removal of sites in a typical user site creation scenario.

In addition to the above Site Policy settings, you can enable Self-Service Site Creation forcing users to select a Site Policy to apply to their site. Finally we have the ability to clean the unused sites out of SharePoint without a delete only option as in the past.

Installing Ruby on Rails using Debian Wheezy

So I am setting up a website for a community band and wanted to try out using Ruby on Rails. The installation of Ruby with Rails is not as easy as I would have thought. After some trial and error here is the smoothest way to get Rails up and running on Debian Wheezy RC.

Firstly get Debian fully updated and edit the apt.config and sources.list files to add support for unstable packages. We need this to install a javascript engine. See my last post for details of this step.

The next thing to do is install all the required packages to get Rugy working.
apt-get -y install ruby ruby-dev rubygems sqlite3 libsqlite3-dev git
Rails will need a javascript engine so install node.js from the unstable repository with this command. Note that once node.js is available in the Testing or Stable package repositories you will not need to tell apt to install from Unstable.
apt-get -y -t unstable install nodejs
Now we can install Rails using Ruby Gems.
gem install rails
As an option, you could install Rails using apt.
apt-get install ruby-rails-3.2
That's it. If you want to use other Ruby frameworks you can install them also. In this case I am going to give RefineryCMS a shot.

Tuesday, 26 March 2013

Installing Unstable Packages on Debian Testing

If you want to install unstable packages onto a Debain Testing installation you will need make the following changes to Apt.

Firstly edit or create the /etc/apt/apt.conf file and add this line;
vim /etc/apt/apt.conf
APT::Default-Release "testing";

Now we need to add the unstable repositories to the sources.list file.
vim /etc/apt/sources.list

Here is the sources.list file I am using at the time of writing.
# Testing Repository
deb testing main contrib non-free
deb-src testing main contrib non-free

deb testing-updates main contrib non-free
deb-src testing-updates main contrib non-free

deb testing/updates main contrib non-free
deb-src testing/updates main contrib non-free

# Unstable Repository
deb unstable main contrib non-free
deb-src unstable main contrib non-free

Lastly update the repositories.
apt-get update
Now if you want to install a package from the unstable distribution of Debian use the apt-get command with a couple of extra parameters   This example is installing nodejs from unstable.
apt-get -t unstable install nodejs

Thursday, 21 March 2013

Installing ownCloud v5.0 on Debian Wheezy using Nginx running on a Raspberry Pi

My last post was about installing ownCloud onto Debian Wheezy using Git. I didn't mention in that post that Debian was running as a Virtual Machine on Windows Server 2012 Hyper-V. This install is working well for me but I wanted to use a Raspberry Pi for the install of ownCloud so I could attach a USB hard disk for storage and use as little power as possible.

I decided to try installing ownCloud with Nginx as the web server because of articles around the web stating that Nginx uses less resources than Apache2.   This being the case it makes Nginx a great candidate for the web server when using a low powered Raspberry Pi as the hardware.

So here is the process I used to achieve my goal.

Firstly we need to get the Raspberry Pi setup with Debian, or as it is called in the Pi world, Raspbian. I didn't need a graphical environment for this setup, so I used a custom version of Raspbian called Raspbian Server Edition.  Raspbian SE was at v2.3 at the time of writing.

We can use the beginners guide to install the Raspberry Pi operating system to an SD card. Just use the Raspbian SE images instead of the full Raspbian image.

Once you have the Raspberry Pi installed and running including a static IP address, SSH server and other standard configurations, you then need to install the required packages;
apt-get -y install nginx php5 php5-fpm php5-cgi php5-gd php5-json php-pear php-xml-parser php5-intl php5-sqlite curl libcurl3 libcurl3-dev php5-curl smbclient cifs-utils mp3info zip git
Just because we have installed so many packages, I feel it is a good time to do a restart and to test the Nginx server is starting after boot. So type the command Reboot and wait for the system to come up.

You can now open a browser and hit the address of your Pi. You should get a warming message as below;

Nginx does not use the /var/www directory by default so lets make that directory and setup security on it;
mkdir /var/www
chmod 774 /var/www
chown www-data:www-data /var/www

Now lets configure the site file for Nginx. Create a new file in the sites-available directory changing the name as desired;
vim /etc/nginx/sites-available/
Now paste in your web server configuration. Here is the site file I ended up with;

# This is the complete example of nginx configuration file for ownCloud 5
# This config file configures proper rewrite rules for the new release of ownCloud
# Also, this config file configures nginx to listen on both IPv4 and IPv6 addresses
# If you want it to listen to IPv4 address only, use listen 80; instead of listen [::]:80

# First, we configure redirection to HTTPS (substitue with the proper address of your OC instance)

server {
  listen 80;
  rewrite ^ https://$server_name$request_uri? permanent;

# Now comes the main configuration for ownCloud 5

server {
  listen 443 ssl; # Make it listen on port 443 for SSL, on both IPv4 and IPv6 interfaces

  root /var/www; # Make sure to insert proper path for your ownCloud root directory

  index index.php;

  # Now we configure SSL certificates. Make sure you enter correct path for your SSL cert files
  ssl_certificate /etc/ssl/localcerts/oc.pem;
  ssl_certificate_key /etc/ssl/localcerts/oc.key;

  client_max_body_size 2G; # This is the first parameter which configures max size of upload, more to come later
  fastcgi_buffers 64 4K;

  # Configure access & error logs
  access_log /var/log/nginx/access.log;
  error_log /var/log/nginx/error.log;

  # Configure proper error pages
  error_page 403 = /core/templates/403.php;
  error_page 404 = /core/templates/404.php;

  # Some rewrite rules, more to come later
  rewrite ^/caldav((/|$).*)$ /remote.php/caldav$1 last;
  rewrite ^/carddav((/|$).*)$ /remote.php/carddav$1 last;
  rewrite ^/webdav((/|$).*)$ /remote.php/webdav$1 last;

  # Protecting sensitive files from the evil outside world
  location ~ ^/(data|config|\.ht|db_structure.xml|README) {
    deny all;

  # Configure the root location with proper rewrite rule
  location / {
    rewrite ^/.well-known/host-meta /public.php?service=host-meta last;
    rewrite ^/.well-known/host-meta.json /public.php?service=host-meta-json last;
    rewrite ^/.well-known/carddav /remote.php/carddav/ redirect;
    rewrite ^/.well-known/caldav /remote.php/caldav/ redirect;
    rewrite ^/apps/calendar/caldav.php /remote.php/caldav/ last;
    rewrite ^/apps/contacts/carddav.php /remote.php/carddav/ last;
    rewrite ^/apps/([^/]*)/(.*\.(css|php))$ /index.php?app=$1&getfile=$2 last;

    rewrite ^(/core/doc[^\/]+/)$ $1/index.html;

    index index.php; # This one might be redundant, but it doesn't hurt to leave it here

    try_files $uri $uri/ index.php;

  # Configure PHP-FPM stuff
  location ~ ^(?<script_name>.+?\.php)(?<path_info>/.*)?$ {
    try_files $script_name = 404;
    fastcgi_pass unix:/var/run/php5-fpm.sock; # Be sure to check proper socket location for php-fpm, might be different on your system
    fastcgi_param PATH_INFO $path_info;
    fastcgi_param HTTPS on;

    # This one is a little bit tricky, you need to pass all parameters in a single line, separating them with newline (\n)
    fastcgi_param PHP_VALUE "upload_max_filesize = 2G \n post_max_size = 2G"; # This finishes the max upload size settings
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; # On some systems OC will work without this setting, but it doesn't hurt to leave it here
    include fastcgi_params;

  location ~* ^.+.(jpg|jpeg|gif|bmp|ico|png|css|js|swf)$ {
    expires 30d;
    access_log off;


Once you have saved the file you will need to make a symbolic link to it in the sites-enabled directory;
rm /etc/nginx/sites-enabled/default
ln -s /etc/nginx/sites-available/ /etc/nginx/sites-enabled/

It's always nice to see some progress being made, so lets make a phpinfo() file and test the web server and php functionality;
echo "<?php phpinfo() ?>" > /var/www/index.php
service nginx restart

Now open a web browser and hit the IP address of your Raspberry Pi. We should see the standard PHP information being displayed.

As with my last post, we need to add the US UTF-8 locale.   I will keep this post short.   See the ownCloud installation process from my last post.

Here are the references I used for this install;