Throughout my day I need to monitor several different looking glasses at my system performance and availability. Not only do I have my distributed SmokePing machines feeding back to my Chicago monitoring server, I have several Cacti front-ends and a half-dozen Nagios boxes (including my internal and external machines and some virtual Nagios boxes we run for a managed monitoring system we offer to clients). Cacti and SmokePing are more documentation and troubleshooting tools to watch system performance, not really notification engines for alerting me to trouble (or potential trouble), so most of my time is spent tabbing through Nagios screens to get a roundup of the current system status in our datacenter and at our clients’ sites.
With so many separate Nagios installations, it’s hard to keep track of which tab is which customer, if I have all the tabs open, and even if the Nagios site is responding or if Firefox is frozen. Enter Nagioschecker, a plugin for Firefox that queries the status of all of my Nagios installations and will display an in-browser alert if/when there is an issue.
All I had to do was configure Nagioschecker with the URL and a username/password for each of my Nagios installations and now it will aggregate the alerts to my browser, no matter where I am at. Once loaded, they will alert me to any issues at any of my sites:
Recently, a customer was curious about implementing Microsoft Office SharePoint Server 2007 inside of their organization. While working with one of their external clients, they were exposed to the collaboration and versioning features of the software and were captivated by the simplicity of the software. As they are TechNet subscribers and Registered Partners with Microsoft, there were no licensing costs for their internal use, so we implemented the software on a VMware ESXi virtual server running Windows 2003 R2 and SQL Server 2008.
SQL 2008 introduces a new aspect to the Reporting Services component: SharePoint Integrated mode. Curious, I read more into this feature and found that it was added to ease the past pain of getting MOSS 2007 and SQL 2005 Reporting Services to integrate properly. Because, though, you need to install SQL 2008 before you install MOSS 2007, I was in a bit of a “chicken before the egg” situation: how can I connect SRS to MOSS when MOSS cannot be installed until SQL is installed? The answer is that I just need to change the configuration once the setup is complete!
Step 1: Install Reporting Services Add-in for SharePoint on the MOSS Server
Once SQL and MOSS are installed on their respective servers correctly, download and install the Microsoft SQL Server 2008 Reporting Services Add-in for SharePoint on the MOSS application server. This add-in basically provides a Report Viewer Web Part that provides report viewing capability, export to other rendering formats, page navigation, search, print, and zoom.
Step 2: Configure Report Server in SharePoint Central Admin Tool.
Once the add-in is installed and ready to go, we need to tell SharePoint to use the reports server in the Central Administration utility. On the MOSS server, open the Programs menu, choose Microsoft Office Server, and then SharePoint 3.0 Central Administration. This will open the Central Administration utility in a browser window. You will need to login using credentials that have access to the Central Administration utility.
In Central Administration, go to Site Actions in the top corner and choose Site Settings:
Under Site Settings, choose “Site collection features”:
Find the Report Server Integration Feature on the list and ensure it is Active (click Activate if it is not marked as Active):
Step 3: Set Report Services Permission to Access Server Farm
Still in the Central Administration utility, click on the Application Management tab on the top of the screen. Locate the Reporting Services section, and click the Grant database access link. Enter the appropriate database server name (in my case, it is the same as the application server), choose your instance (in my case, the Default Instance) and click OK.
You will be prompted for a user account and a password; you must choose a user account with sysadmin access to the Reporting Services server (I used my domain admin account). This is a one-time login to gather info on the instance, and it will not continue to use your credentials to access SRS.
Step 4: Configure Reporting Services Integration
To activate Reporting Services in MOSS, you need to provide the URL to the SRS install to MOSS. From the Application Management tab in the Central Administration utility, click on “Manage integration settings” under Reporting Services. Here, enter the URL to the SRS installation (in my example, the SQL server is named www01 so my URL is http://www01/ReportServer). If your reports will use Windows Authentication, you must choose Windows Authentication here. If you will be using trusted connections in the published reports, you can use Trusted Account in the Authentication Mode. Press OK when you have entered the URL and chosen an authentication method.
And now you are set! You can publish your reports from Visual Studio and then view them in the MOSS Report Viewer Web-part that was installed and made available by the Reporting Services Add-in for SharePoint. Again, if you have issues or questions please don’t hesitate to contact me or leave a comment.
Even the setup of this very blog was wrought with an un-documented issue with URL rewriting. Most SEO experts worth their titles know that Google and other search engines recognize “www.domain.com” and “domain.com” as two distinct sites and split your results and ranking between the two. The ultimate goal is to try and combine your traffic down to one distict URL and prevent dispersing your rank. In the case of my blog, I chose to redirect all traffic to www.jomofojo.co, which means if someone types some url without a www, it should be redirected automatically.
A simple redirect will take any URL containing jomofojo.co and send it to http://www.jomofojo.co. This is not optimal if someone is trying to get to my Contact page (https://jomofojo.co/contact.asp) and is instead sent to my home page (http://www.jomofojo.co). A context-sensitive redirect will maintain any trailing path on the URL when redirecting to the new host (so https://jomofojo.co/contact.asp becomes http://www.jomofojo.co/contact.asp). From a systems-management perspective, the simple redirect is far easier to implement with three lines of code in my header. However, from a user-experience perspective, the latter option is 1000 times more efficient and friendly, but it requires coding on every page of my site or configuration changes to my web server. Below you’ll find options for how to implement this change for either your web server or in the code of your site.
Code Approach: ASP
For ASP, merely add the following to the top of every ASP page in your site, or paste it to a single file and include it before the <html> tag in each of your pages:
If InStr(Request.ServerVariables("SERVER_NAME"),"www") = 0 Then
Response.Status="301 Moved Permanently"
Code Approach: PHP
For PHP, merely add the following to the top of every PHP page in your site, or paste it to a single file and include it before the <html> tag in each of your pages:
In order to redirect to the www URL in Apache, you must install and configure the mod_rewrite plugin. Once that is complete, create a new .htaccess in the root of your site and add the following lines, where domain.com is your domain:
By default, IIS 6 and earlier did not come with a URL rewriting utility. Helicon has a product named ISAPI_Rewrite for sale that does an excellent job and uses most of the same syntax as mod_rewrite in Apache. The correct httpd.ini configuration for ISAPI_Rewrite 3.0 and later is: