As a normal user, open a Terminal window and enter alsamixer. Press F6 and then unmute all of the audio channels (do so by selecting them with the arrow keys, and then pressing ‘m’. When done, press ESC to exit.

After this, su - to assume root, and then type aplay -l to get a list of your audio devices. In my case, I’ve disabled the onboard audio, so the only devices are the Nvidia ones. The output will look something like this:

root@wormwood ~]# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: NVidia [HDA NVidia], device 3: HDMI 0 [HDMI 0]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: NVidia [HDA NVidia], device 7: HDMI 0 [HDMI 0]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: NVidia [HDA NVidia], device 8: HDMI 0 [HDMI 0]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: NVidia [HDA NVidia], device 9: HDMI 0 [HDMI 0]
Subdevices: 1/1
Subdevice #0: subdevice #0

Note that while there are four devices, the first one (which Pulseaudio selects by default) doesn’t do anything. To get this to work, we need to tell it to use the second device (#7). This isn’t horribly easy. If you have another sound card, note the device numbers listed for it above – you’ll need them in a minute.

Finally we can tell Pulseaudio to actually use the correct devices. Still as root, open up /etc/pulse/default.pa and find these lines:

### Automatically load driver modules depending on the hardware available
#.ifexists module-udev-detect.so
#load-module module-udev-detect
#.else
### Alternatively use the static hardware detection module (for systems that
### lack udev support)
#load-module module-detect
#.endif

Now, comment them all out as I have done above. This prevents Pulseaudio from trying to be smart. Now, scroll to the end of the file and add the following line (if you have more than one audio device, you will need to add it multiple times with the correct card and device numbers that you gathered from aplay above):

load-module module-alsa-sink device=hw:0,7

Now simply do a killall pulseaudio and try to play something. You should have audio output over HDMI now!

Edit: Just a bit of follow-up if you’re having trouble with the sound muting after every reboot. As root, enter the following in a shell:

touch /etc/asound.state

chmod 777 /etc/asound.state

Now, as a standard user, follow the instructions above to unmute the Nvidia device channels via alsamixer. Once you’ve confirmed sound is working again, from a shell (still not as root!) type:

alsactl store

Now go back as root and:

chmod 644 /etc/asound.state

When you reboot, you shouldn’t have to unmute through alsamixer anymore.

Fortunately, because it’s written in Java there’s a little trick you can you to speed things up a little, assuming you have a decent amount of free RAM. The manager console is typically launched through sesm.bat, which is located (in a default install on an x64 server) in “C:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\bin\”. Open that .bat file in notepad, and you’ll see this:

@start “SESM” “C:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\jdk\bin\javaw.exe” -Xms128m -Xmx1024m -XX:MinHeapFreeRatio=30 -XX:MaxHeapFreeRatio=40 -Dscm.console.conf=”C:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\tomcat\etc\conf.properties” -jar “C:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\tomcat\webapps\scm\clientpkg\scm-ui.jar”

Note the bit that I’ve highlighted above in red. Boost that up a little (I set it to 512m), save, and then re-open the management console. You should notice a significant difference in how fast the console operates now.

I got the new set of cables today and, of course, they were all 0.35mm thick as well. I tried a few techniques to try to make the ends thinner but eventually just ended up with a bunch of butchered ribbons.

Remember kids, always review the specs of the drive and cable *before* ordering!

So I’ve ordered another batch of cables, this time making sure that one end has the correct thickness. Hopefully I’ll have a working netbook in a few weeks.

Update: The new ZIF cable came in (ProTip: when ordering ZIF ribon cables, if you need a smaller-than-0.35mm end, look for one where one end is blue (as pictured above), and the other end is white. The white end will be the smaller size)! Surprisingly, it fit, and after making a few modifications to the case (mainly removing the screw mounts for the old SSD) the new drive just dropped right in to place. Xubuntu is now installing, so I finally have a functional netbook again!

I use OpenDNS, so I’m used to search pages coming up when I mistype URLs, however that is something I’d opt’ed in to. You can imagine my surprise when, after mistyping a URL, I was directed to this instead:

http://assist.shaw.ca/shawcaassist/dnsassist/main/?domain=www.example.com

(original URL redacted).

It appears that, even if you aren’t using Shaw’s DNS servers they are still checking your DNS requests and, in the case of NX domains (at least – they could technically do this for any traffic), hijacking the result and forwarding your browser to their page instead.

I’ve sent a barrage of messages to Shaw’s PR team on Twitter, but haven’t had a response yet. I’ll update this article when (or if) they reply.

For the time being, though, it appears you can opt-out of the ‘service’ using this page: http://nxr.shaw.ca/optout/

Update: I’ve had a reply from Shaw saying “We do not modify any DNS traffic going to our customers from other sources”. They’re currently looking in to the issue apparently, so another update will be in order when I hear back.

Additional Update: I received a reply from Shaw asking me to do some further troubleshooting, all of which would have been useless (eg, using the ‘dig’ and ‘nslookup’ commands to confirm my DNS settings and what the NX response was), however as I opted out of the ‘service’ I can’t actually complete the steps as everything is working correctly. Additionally, there doesn’t appear to be a way to opt back in to the ‘service’, so that’s also a bust. I guess I won’t be getting an answer as to what happened. Also, I was linked on Reddit Canada.

• 1x Windows Server 2008 R2 with Hyper-V/AD/File Server roles, and two shared folders. Server has dual onboard NICs, one with full access to the client network below, the other to a separate network to allow the server to be managed remotely (no gateway configured on this NIC).
• 18x Windows 7 x86 clients
• Standard network setup (read: no VLANs, bridging, etc…. Just one network switch).

The previous server used by these clients worked perfectly. However, upon replacing the server with the one above, my users began noticing an odd issue. If they copy one or more files/folders to a share that is visible to all of the computers, the file(s) don’t immediately show up on all of the computers – usually 3/4 of the computers will see the file(s). On the 1/4 that don’t, users either have to wait ~10 minutes before the files will appear, or they can reboot to force a refresh. Simply pressing F5, or right-clicking in the shared folder and choosing ‘Refresh’ doesn’t work – only waiting or rebooting does.

In terms of a solution, I’ve seen a number of suggestions, but none seem to work. The server has dual-onboard Broadcom Gigabit NICs, and a number of forum posts have suggested disabling Checksum Offload and Large Send Offload, but this made no difference. Neither did disabling IPv6 on the client and server side. Disabling firewalls on the client and server side made no difference, nor did this post suggesting a few registry settings to change.

What did fix the issue, though, was disabling SMB2. Once all of the clients were connecting using the old SMB protocol the issue disappeared. I have no idea why SMB2 is an issue as I haven’t take the time to troubleshoot further with SMB2-specific settings, however this at least has things running normally.

TL;DR Version: If you have clients connecting to a Windows Server 2008 R2 box and the contents of file shares aren’t refreshing immediately or until reboot, disable SMB2 on the server.

When it comes to forcing clients to recognizing the new server, Symantec recommends that you use it’s “SylinkReplacer” tool. This, however, is a poor option as you have to have a whole mess of firewall entires setup in advance (such as enabling SMB on all affected computer and creating exceptions for that), or have the firewall turned off completely. In a lot of environments this just isn’t possible.

As such, I started hunting around for an alternative and came across the aptly named “SylinkDrop” tool, located in “Tools\NoSupport\SylinkDrop” on the SEP DVD (or in the .zip if you downloaded it from Symantec). This tool is a lot simpler in nature – it force-stops the SEP services, replaces the Sylink.xml file, and restarts the services. The catch? It only runs locally. Fortunately, it comes with command line options and can run silently!

The solution is simple – drop the SylinkDrop folder in a network share accessible to the affected clients (in my case, clients have X: mapped to common folder). Copy Sylink.xml from a client computer that is connected to the right server (I uninstalled SEP manually on one client, the reinstalled it and copied file from there) to the the SylinkDrop folder. Then, create a .cmd file (or .bat if you like that kind of thing) with the following:

@ECHO OFF

if exist c:\windows\sep-replaced.txt goto :exit

REM Replace the Sylink.xml with a new one pointing to the correct server

X:\SylinkDrop\SylinkDrop.exe -silent X:\SylinkDrop\SyLink.xml

REM Mark the system as having been updated

echo 1 > c:\windows\sep-replaced.txt

:exit

exit

That’s it! As your users reboot their computers and login, the tool will run and the computers will start showing up in the SEP Manager Console. Once all of the computers have been updated, go in and delete the entry from the login script and remove the folder from the share. You’re done!

Edit: It’s worth pointing out as well that you can can login to the SEP Management Console, choose the ‘Clients’ tab, and click ‘Find Unmanaged Clients’ on the bottom-left. This will let you search by IP-range and do a full install (Windows only).

So I found myself faced with an issue – I was about to go on a fairly long trip, however I was planning on taking a route different from the one Google had suggested. While I could use the web version of Google Maps on my phone, I wanted to use the actual app. The solution, as it turns out, is very simple.

The trick is to set everything up on the web version of Maps first. This gets tricky, depending on how sever the changes to the route are. I my case, I only needed to drag one route marker to change the route to go where I wanted it. Here’s the before route, and the after (not my real start and destination, just an example).

So the cheat is actually very straight forward – after finalizing your route in web Maps, copy the link for the map (don’t use the address bar – use the Link button in the top-right corner of the map) and paste it in to a URL shortener like Is.Gd, then enter that URL on your Android phone. The browser will ask if you want to open the link in Maps or another program, so just choose maps and your custom route will appear, with full directions, right before your eyes.

Edit: I should clarify that Google Navigation for Android has a ‘Recalculate Route’ option, however if you aren’t planning on using it, or it isn’t available in your area, this is the solution.

]]> http://laslow.net/2010/12/16/cheat-how-to-get-custom-routes-on-google-maps-for-android/feed/ 3 http://laslow.net/2010/10/22/a-php-based-server-monitor/ http://laslow.net/2010/10/22/a-php-based-server-monitor/#comments Fri, 22 Oct 2010 17:46:54 +0000 Laslow http://www.laslow.net/?p=1043 The other day I decided that the little ‘Network Monitor’ desktop gadget I was using to monitor my few servers just wasn’t cutting it. Instead, I wanted to make use of a spare iMac and have something a little flashier. A Google search for Server Monitors brought up a plethora of options that were either horribly ugly, platform specific, or just didn’t work the way I needed (most required that the target server be running some form of web server, such as IIS or Apache to retrieve headers to see if the server was up – most of my servers don’t run those). As such, I decided to write a small script from scratch.

I figured the easiest way to accomplish my goal of a platform-independent monitoring script was to use PHP. After enabling Apache2/PHP5 on my Snow Leopard-running iMac (a topic for another blog post later), I searched through the PHP.net function list until I found fsockopen(). This function is quite ideal, as it will work with any open port. The first step was to make a quick function to utilize fsockopen and return some testable results:

function checkServer($ip,$port)

{

$fp = fsockopen($ip,$port,$errno,$errstr,1);

if (!$fp)

{

return ‘Down’;

} else {

return ‘Up’;

}

}

I added this to a <?php ?> block in the <head></head> of the document – to call the function and perform the test, I used the following line below:

$servername = checkServer(’192.168.1.100′,’53′);

In this example I’m checking the availability of a DNS server, so I use port 53. When this runs, the $servername is set to either ‘Up’ or ‘Down’ depending on whether or not a connection can be opened on that port.

The only thing left now was to display this output. I made a fancy table-based page with graphics where each server is a cell and the background changes between green and red depending on the $servername value. However, all you really need is the code below in a <?php ?> block in the body of the page:

echo(‘Server Example Status: ‘.$servername);

Changing Example to the name of your server. If you have more than one server to check, just make another variable, use the checkServer function to give it a value (make sure to change the IP address and use an open port!), and then add another echo line.

That’s it! To be fancy, you can add a javascript automagic page refresh to – just change the <body> tag to:

<body onLoad=”Javascript:timedRefresh(30000); display();”>

And put the following in the <head></head> section:

<script type=”text/Javascript”>

<!–

function timedRefresh(timeoutPeriod) {

setTimeout(“location.reload(true);”,timeoutPeriod);

}

//  –>

</script>

And you’re done! If the server is up, every 30 seconds your page will refresh and show:

Server Example Status: Up

Background
I work for a non-profit organisation that’s primarily funded by the government. As such, we receive only a little funding for ‘technical extras’, and sadly even a cheap Class 2 SSL cert is out of financial reach at this time. The has caused a bit of a problem.

We run an Exchange 2007 server on a Windows Server 2003 box with Active Directory in along side the primary and secondary domain controllers. Our internal network was setup (by my predecessor) as foo.local. Our email, on the other hand, is hosted externally (as our ISP does not allow email servers on business accounts – go figure) on the domain mail.bar.com. Because of foo and bar, a single Class 1 Cert can’t be used – and therein lies the problem.

When I access OWA (Outlook Web App) internally, I can use the internal name of the mailserver (mail.foo.local), which uses a self-signed Class 1 Server SSL cert by the Windows Server built-in certificate authority.  Of course, when accessed externally, my browser flips out because it doesn’t recognize my own certificate authority as valid and the name on the cert itself doesn’t match (mail.foo.local compared to the external domain exchange.bar.com). Although this is technically alright, because I know enough to verify the cert manually, this confuses my users and can potentially lead to man-in-the-middle attacks.

The Solution
IIS only allows one SSL cert per Web Site. Without a Class 2 SSL cert (they allow for multiple domains to be specified) it isn’t technically possible to have two domains SSL-protected. If I apply a valid Class 1 cert for the external domain, the internal Outlook clients will throw the SSL error instead, which is much more of a problem.

Therefore, the solution is two create a second Web Site (with different port assignments, otherwise you need a second NIC and IP address) in IIS and mirror the OWA and ActiveSync Virtual Directories. This is actually easier than it sounds. Note that the following instructions are for IIS on Windows Server 2003, and Exchange 2007.

1. Open IIS, then expand the Web Sites entry.
2. Right-click on the Web Sites entry and choose “New” -> “Web Site”.
3. Choose “Next”, then give it a name (and remember it – I chose “OWA-External”), and “Next” again.
4. If you have a second NIC/IP address on the server, specify it. Otherwise, change Port 80 to an unused port (I choose 82), then click “Next”.
5. Choose a new folder to be the root of the website. It’ll stay empty, so it doesn’t matter where you put it. I created C:\inetpub2. Click “Next” again.
6. Leave the defaults selected (Read), then click “Next” and “Finish”.
7. Right click on the new website (“OWA-External” in this example”) and choose “Permissions”.
8. Add the “Internet Guest Account” for your server (typically, DOMAINIUSR_SERVERNAME) and give it Read, Read & Execute, and List permissions.
9. Click OK and close IIS.

Now that the website is setup, we need to tell Exchange to create the Virtual Directories. If you try to manually create them in IIS by mirroring the settings from the existing entries under the Default Web Site, you won’t be able to access OWA.

1. Open the Exchange Management Shell.
2. Type Get-OwaVirtualDirectory and press Enter. This will show the existing Virtual Directories.
3. Now type New-OwaVirtualDirectory -WebSiteName “OWA-External” (replacing OWA-External with your website name) and hit Enter. It make take a minute or two to process, depending on the speed/load of your server.
4. If you don’t get any errors, type Get-OwaVirtualDirectory again and you should see a new owa entry in the list.
5. Next is to create a new ActiveSync Virtual Directory in the new site. The command to do that is New-ActiveSyncVirtualDirectory -WebSiteName “OWA-External” -ExternalURL “http://exchange.bar.com/Microsoft-Server-ActiveSync” (replacing OWA-External and the URL with your own, of course).

Now open up the Exchange Management Console. Browse to Server Configuration -> Client Access. Under the Outlook Web Access and Exchange ActiveSync, you should now have two entries each – one for the original Web Site (usually Default Web Site), then one for the one you just created.

Now you’re almost done. Back in IIS, open the Properties for the new Web Site and set your SSL port to something other than 443 (unless you have two IP addresses on the server), then install your valid Class 1 SSL cert for your external domain (exchange.bar.com, in this example – I got my Class 1 cert free from www.startssl.com). The only thing left to do now is to port forward. On your router/gateway/firewall/whatever, forward port 443 to your Exchange server’s IP (or second IP if you’ve set it up that way) and, if appropriate the correct port. In my case, I forward port 443 to port 444, as well as port 444 to 444. Both are necessary if you’re using a port other than 443.

Once all this is done, restart IIS on your server and all should be ready. You’ll now have a valid cert internally and externally!

I’m no fan of browser redirects in any form, and I’m even less of a fan of Yahoo which Rogers partners with to, among other things, provide results on their hijacked landing page. But what can you do? It’s their service, and there’s no opt-out link on the page.

Well, the answer is to manually opt-out. Unfortunately, you need to have a rooted/jail-broken phone to do this. As stated above, I have a Google Nexus One which runs CyanogenMod, but this should work with any other rooted Android phone and even jail-broken iPhones (although the paths are different — you’ll need to alter them as applicable).

To manually opt-out, do the following (assumes Android phone):

1. Open a shell on your phone. You can use ConnectBot, Terminal Emulator, or adb shell.
2. Assume root (su command).
3. Remount the system partition in to read/write mode —  mount -o rw,remount /system
4. Browse to /system/etc.
5. Use your favourite text editor to open hosts.
6. Add the following to the bottom of the hosts file — 127.0.0.1 www20.search.rogers.com
7. Save and quit!

You’re done! You’ve just manually opt’ed-out of Rogers Wildcard DNS hijack. Now you’ll just get the normal ‘Not Found’ errors, as when Rogers see that the domain you’ve entered doesn’t exist and tried to redirect you to their search page, your phone will point that domain to itself and fail as it isn’t running a webserver.

TL;DR Version: To prevent getting directed to Rogers’ Search Page when you mistype an address, edit your hosts file to point www20.search.rogers.com to the 127.0.0.1 loopback address.

Update (05/01/2011): You can now officially opt-out using this link: http://searchassist.teoma.com/templates/rogers/optout