Posterous theme by Cory Watilo

Upgrading our mojoPortal install

It seems no matter how many times I've upgraded mojoPortal, I'm always at a loss as to where to begin. I've done it enough to know that it's nothing to be afraid of, but it does take some elbow grease. In addition to making sure that the upgrade goes smoothly in itself, I also always have the concern of leaving the version control system which I use to track my customizations in a working state.

This second comes into play primarily because the mojoPortal upgrade approach which I take is a customization forklift onto an entirely new set of code. I don't try to overlay the update on the old site. Rather, I unzip the new code and bring over all of the customizations. This means that from a version control perspective, I'm not making modifications to an existing family of changed files, I'm nuking the files back to zero and redoing all of my customizations on top of them. If I'm not careful, this has the effect of collapsing all of my history into one big changeset, and I don't like losing that history.

But before delving into too much detail on the version control, focusing on the upgrade itself is the primary concern.

The overall process goes:

  • review and commit any pending changes
  • backup the database
  • get the new code
  • migrate all of the customizations over (getting the vc right)
  • stop the web service
  • switch the new directory in for the old one
  • start the web service
  • visit the setup page for the new version (http://support.diditbetter.com/Setup/Default.aspx)
  • Check the security settings from the administrative interface
  • backup the old directory

You always want to make sure you check the mojoPortal release notes for the releases between your last and this one to see what caveats there are about this version.

Sometimes there are considerations for skins as well in the new version. Usually old skins won't break, but there are pages on the mojoPortal.com site which discuss upgrading skins.

Why do an upgrade by customizing the new code instead of dumping the new files on top of the old site? In the end, it's because it's generally the same amount of work and ends up with a cleaner install. Here's the reasons:

  • Sometimes files are removed or renamed in the new version. If you just overwrite the old directory, the old files won't be removed, and while this usually shouldn't matter, why take the risk?

  • Many configurations would be overwritten if you just copied over the old site. While the binary files need to be replaced, and even the configuration files need to be updated with new settings, the old customizations would get removed by simply dumping on top of the files. While user.config handles some of this, there are still customizations that occur to web.config and other files which can't be lost.

So, here are the steps in more detail.

Review and commit pending changes

  • Log into mojo-a and go to E:
  • Right-click diditbetter and select Hg Commit
  • Review any changes and commit them if desired
  • Go to \diditbetter\Data\Sites and visit the skins directory under each site
  • In each skins directory, right-click any custom skin (like diditbetter3) and review and commit any changes if desired

Backup the database

This can be done easily from SQL Management Studio.

  • Log onto mojo-a
  • Open SQL Management Studio
  • Connect as sa
  • Open Databases
  • Right-click mojoportal and select Tasks > Back Up
  • Select type Disk and click Add...
  • Name the file mojoportal.sql.[YYYY]-[MM].bak, where YYYY is the four-digit year and MM is the two-digit month
  • Put it in the default backup directory
  • Click OK until the backup is performed

Get the new code

  • Go to http://mojoportal.codeplex.com/
  • Download the latest .NET 4, MSSQL deployment files (generally this is the default download)
  • From the zip, copy the wwwroot folder to E:

Check whether there are skin modifications with the update

Usually, the changes that affect the skins are in the theme.skin file, which may or may not be customized by us, so check the repository history for the theme.skin file before just overwriting it with a new version from the upgrade's default artisteer skins.

Migrate the customizations over

This is the hard part. Not only do the files have to be right, the filesystem permissions need to be correct as well.

  • In wwwroot, delete Data\Sites (usually there will be one site called 1)
  • From diditbetter, copy Data\Sites to wwwroot
  • In each of the sites in this copy, delete all skins which aren't necessary (Data\Sites\[site number]\skins). Leave the custom skin for the site.
  • Copy the printerfriendly skin from \wwwroot\Data\skins
  • If you need skins in the future, copy them here from Data\skins, which are up to date with the latest version
  • Create a new repository in wwwroot
  • Copy .hgignore from diditbetter to wwwroot. It should contain one line: glob:*
  • Right-click e:\diditbetter and select Hg Workbench
  • Review the changelog for the site and make sure all of the changes make it over. First, copy user.config.sample to user.config and add the upgraded version of edited files to the repository (the ones that came in the zip, prior to editing). Then move over the edits (don't just drop the old files over the new ones!) one by one, committing them with the same commit messages as they had in the old repository. WinMerge is good for this so you don't just overwrite the new file with old baggage. This should include:
    • Basic web.config and user.config settings
      • UseRelatedSiteMode on so that the same user db is used across sites
      • The machine key is preserved from the old site, otherwise logins won't work
      • The database connection string is brought across
      • Email settings are configured
    • More user.config optimizations
      • UseKeepAlive is set to keep the site responsive
      • Notify admins on new registrations is on
      • Show the "rebuild search index" button to admins
      • Allow forcing of the preferred hostname for the site
    • Custom registration configuration
      • CustomProfile.config added
      • App_GlobalResources.resx edited with new fields
      • user.config configured with name of CustomProfile.config
  • Additionally, you have to copy over these files:
    • iirf.ini is the configuration file for URL rewriting/redirection
    • These files are for IIS to do redirects:
      • activate.aspx
      • blog-rss.aspx
      • downloads.aspx
      • news-rss.aspx
      • support-rss.aspx
    • Any custom scripts in the ClientScripts directory should be copied over including:
      • coda-slider.js
      • jquery.localscroll-1.2.5.js
      • jquery.scrollTo-1.3.3.js
      • jquery.serialScroll-1.2.1.js
  • Set the file permissions for Network Service on the wwwroot folder
    • Add Network Service to the top level with default rights plus an explicit deny for Write
    • Go to the Advanced settings, select Replace permissions... and click Apply
    • Add an explicit allow for Write for Network Service to the App_Data and Data subdirectories, also forcing it onto all subfolders and files
  • Stop the W3 service, rename the old diditbetter folder and name wwwroot in its place
  • Start the W3 service, then visit: http://support.diditbetter.com/Setup/Default.aspx. This will take some time since the site has to recompile all of its files.
  • Zip up the old site directory and archive it for safekeeping

Once the upgrade is complete, put the system through its paces, keep an eye on it for a while and check the event viewer logs for errors.

Use arbitrary fonts on the web with cufón

http://cufon.shoqolate.com/generate/

-- Shared with Google Share Button

Found this neat tool.  It has one major caveat, but for its purpose it's great.  The purpose in question would be to use an arbitrary font (which you have license to and have as a TTF or OTF) on the web with good speed.  Works with all of the major browsers and any font.

The caveat is that the font is rendered in VML, which apparently makes the text not selectable.  That's a pretty big drawback for a lot of text, but may be forgivable on headings and logos, which is where I plan to use it.

The basic method of use is to upload your font to the tool's website, which converts it into a Javascript file.  Along with that, you add the cufon core Javascript to your web page, tell it what selector to render the text with your font, and then initialize the script.  Works fast and looks beautiful.

Identifont identifies fonts by description, partial name or sample

http://www.identifont.com/

-- Shared with Google Share Button

If you work with the web, you work with fonts, it's that simple.  Along with graphics, fonts carry a tremendous amount of emotiveness.  Choosing the right font can make or break that feel you want for your site.

Unfortunately, fonts aren't easy to deal with.  First of all, there's a zillion of them.  Additionally, once you find one you want, it's usually one you have to buy!  All those fonts don't come cheap.

So, what's there to do?  Unfortunately, I haven't found a way to get the web to tell me "what's a free font that looks like this commercial one?".  However, you can describe the characteristics of the font you want to the Identifont service, and it will give you a list of similar fonts, some of which *may* be free.  It requires a bit of elbow grease and it's not 100% successful, but I *have* been able to find free font substitutes for the ones I've wanted by using it.

If you're just looking for the name of a font that you have in a graphic, you can use Identifont or the also excellent WhatTheFont! service at http://new.myfonts.com/WhatTheFont/, part of MyFonts.

How to determine what services are running under a SVCHOST.EXE process

http://www.bleepingcomputer.com/tutorials/list-services-running-under-svchost.exe-process/

-- Shared with Google Share Button

Here's a good article on how to examine what services are running under a particular svchost.exe.  You can inspect svchost.exe with the excellent Process Explorer from Sysinternals.

Of particular interest is the section on setting the grouping of services via the registry.

Getting rid of "float: left" on mojoPortal's ASP.NET menu when using Artisteer

I started a new skin for another site using the latest artisteer30 skins in 2.3.7.0.  Artisteer 3 of course.

In the process, I went a bit deeper on making layout.master's tree structure match that of what Artisteer generates.  I got everything on this new skin looking great, but my old friend the pesky float was there, of course.

Looking back at the article on The Trouble With ASP.NET Menu, I saw the explanation for the additional classes is the Javascript associated with the menus.  I tooled around with this a bit and found a solution to disable that Javascript, so I figured I'd share it here. Fortunately, it's very simple.  See what you think.

The additional attributes on the menu markup, including the style: floats, comes from the ASP.NET AJAX scripts made specifically for the menu.  According to the articles I read, the script in question is fed to the page as "ScriptResource.axd", along with a set of query parameters tagged on the end to identify the desired script, since there's more than one.

Looking through the two ScriptResource.axd references served by the new design, I found the one that was manipulating the menu markup.  So far, so good.

I also ran across two articles on how to override these scripts through markup in the layout.master file.  They arehere and here.  Apparently, the scripts are housed in .NET assemblies and pulled at run-time, so you can't change those scripts directly but you can instead specify that ASP should pull them as plain .js files from a path on your site.  Here's the additional markup:

<asp:ScriptManager ID="ScriptManager1" EnablePageMethods="true" runat="server" >
<Scripts>
<asp:ScriptReference name="MenuStandards.js" assembly="System.Web" path="MenuStandards.js"/>
</Scripts>
</asp:ScriptManager>

The MenuStandards.js script does all of the manipulation.  To see it, you can either save the source of this script from the page before you update layout.master or you can download it from Microsoft's CDN at http://ajax.aspnetcdn.com/ajax/4.0/1/MenuStandards.js.  In fact, you can see a listing of all the scripts available from the CDN at http://www.asp.net/ajaxlibrary/CDNAjax4.ashx.

If you add the MenuStandards.js file in the same directory as layout.master and use the above scriptreference markup, you'll achieve the same effect with the page as the original, however it will be fetching MenuStandards.js from the filesystem and not from ScriptResources.axd, thus giving you control over what the script can do.

There would be two approaches, the surgical and the brute force.  The surgical method would be to cut out the pieces that you don't want from MenuStandards.js and leave the rest.

While this would probably be advisable when you aren't sure what functionality is supplied by the script aside from the annoying floats, I went with the brute force approach and it seems fine for me so far.  The brute force approach is of course to just empty out the file.  The menu renders as Artisteer intended now, at least with this skin.

For the record, I tried various methods of avoiding having to have a blank .js file by, for example, not including the path attribute in the scriptreference, but I couldn't find a way to make that approach work.

Hope this helps someone else as well.

One more thing, the technique on how I found the script name (and assembly) in the first place, since you can't divine that from ScriptResource.axd.  I found an article here which told me you can completely override all of the .NET scripts using a  scriptmanager attribute ScriptPath, which forces it to look for all such ScriptResource.axd scripts on the filesystem.  Doing this led to a combination of exceptions and 404s on the scripts the page was looking for, all given by their regular name and filesystem path.  The path happens to include the assembly name.  You can download each of the named files from the MS CDN (link above), create their path and put them in there to get past one exception to see the next.  Voila.

 

Research Finds that Privacy Tools Don’t Work | Naked Security

http://nakedsecurity.sophos.com/2011/11/07/research-finds-that-privacy-tools-don%e2%80%99t-work/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+nakedsecurity+%28Naked+Security+-+Sophos%29

-- Shared with Google Share Button

Here's an interesting article on security and information privacy.

I tend to be a bit paranoid about how much information about my surfing is tracked by these companies and what they are able to do with it.  Moreover, I don't appreciate the fact that advertising can actually become an attack vector for bad guys to take over my computer.  That's why I take several steps to prevent such tracking and advertising.

Some of the steps I take do, to some degree, affect the usability of my browser.  I have to approve certain sites before they will work as intended, usually for downloads or video.  However, that's only the most stringent of my chosen tools, ScriptNo for Chrome.  A number of other tools are available that have little to no impact on my browsing and go a long way toward protecting my privacy.

I should note that most if not all of these tools are specific to the browser you use.  I don't recommend using IE in any circumstances (except Windows Update, where you are forced to).  I prefer Chrome and recommend it to anyone.

The one privacy-related tool I use that isn't browser-specific is Panda Cloud antivirus.  It is ant-spyware as well, and occasionally it finds a tracking cookie that it will neutralize for me, but it seems to wait for me to run a scan manually, as opposed to automatically neutralizing it in real-time for me.

The rest are browser extensions or settings.

The first setting I use is Chrome's no-third-party-cookies setting.  While I can't get away with this at work, where I have a site that needs a third-party cookie (don't ask), on the Internet this should work without any kind of negative impact in the vast majority of cases.  I use it on all my personal computers and it works fine.  It also tells me, by virtue of the fact that it shows an icon in the address bar when it blocks one, that just about every site on the Internet tries to set third-party cookies.  My assumption is that the vast majority of these are trackers for advertising.  I've already blogged about this tool and how to set it here: http://transfermodeawesome.posterous.com/disable-third-party-cookies-in-google-chrome

If you want to get really zealous, you can tell Chrome to dump all cookies after it exits, but I don't recommend this.  It forces you to re-login to any sites you use regularly, which is an annoyance, and your actions are still trackable within any given session, just not between sessions.

The second thing I use is Google's Keep My Opt-Outs extension.  What this does is adds you to a registry that allows ethical advertising trackers to give you a single opt-out from all of them.  While you should never completely trust a single, voluntary measure to keep away prying eyes, this is an easy way to cut a lot of them out.

Third, I use AdBlock, which out-and-out removes the vast majority of ads from my browsing experience.  While this may or may not block the trackers that they use to monitor browsing (I don't know), it definitely keeps me from intentionally or accidentally clicking advertising, an action which explicitly gives advertisers information about me.  AdBlock is very easy to use.

I recommend all of these tools, as they don't tend to impair browsing and they afford you some extra privacy.

The last tool I use, ScriptNo, is very effective at cutting out these trackers, as it gets rid of multiple types of trackers, including webbugs, and it straight-out blocks browser access to any unknown domain.  It also blocks specific ad and malware domains.

In fact, ScriptNo is more of an anti-malware tool than privacy tool, it just so happens it is good at that as well.  I *strongly* recommend it if you do any kind of serious financial work on your computer, especially if you run a business.  If fact, if you run a business from your computer, you should really dedicate a machine to have access to your bank accounts and do *nothing* else from that computer in order to protect it from infection.  There are malwares out there which will allow bad guys to drain your bank account, frequently without you knowing about it until it is dry.

However, ScriptNo radically impacts your browsing.  It assumes every site should not be allowed to run scripts nor use a number of other techniques in wide use across the Internet, sometimes for good functions and sometimes for bad ones. You should be ready to put some work into a tool like this, but the safety and privacy it gives are substantial.  An ounce of prevention can be worth colossal amounts of cure when it comes to malware.

The impact I'm talking about is that you have to manually approve each site that you want to be allowed to use these tools such as scripts.  Unfortunately, almost all sites use them.  Fortunately, though, most don't actually need them, since they are using them for "extra", and sometimes unwanted, functionality such as advertising tracking.  Still, many sites, including ones that are trying to allow you to download software or ones that show video, will look broken when you visit them.  Frequently, you will need train ScriptNo to temporarily or permanently allow the site to use its content, and not only that, you may need to enable one or more third-party sites with unintelligible names as well.  This can be rather intimidating and annoying just to see a video, but sometimes that is a worthwhile price to pay.  I know this tool has saved my machine from infection more than once, and I'm willing to pay that price in return.  Fortunately, ScriptNo allows you to consult the Web on Trust site-safety-rating tool on any of the blocked sites, which makes it easier to be selective about the sites you trust.  Unfortunately, there is no way of sharing your training info between machines, so you have to go through this process on every computer you own.

That's it!