Random Acts of Geekiness Pontificating on the particulars of programming.

19Nov/130

What do Guard, MUnit and Growl have in common?

For those not familiar, Guard is a super handy Ruby Gem that looks for File changes in a folder.  It's incredibly helpful for when you are doing Unit Testing.  I put together this Guardfile for MassiveUnit that will echo the results to console and will also dispatch a Growl notify event.  You can easily adjust the pass and fail icon urls as well as toggle verbose mode.

The Guardfile is here on GIST. Enjoy!

11Jun/120

Finally dual Gigabit NIC possibilities for MacMini’s

Apple announced a lot of neat stuff at today's 2012 WWDC event.  One little update was the addition of a Thunderbolt to Gigabit Ethernet Adapter for the Ethernet port-less MacBook Pro.  For us MacMini server folks this means that we can finally add a speedy 2nd Ethernet port on your MacMini server. Finally we can have actual network redundancy.  I'm also hopeful that this will increase the amount of network bandwidth a Mini can handle.  I specifically am hopeful that I can finally dedicate one Ethernet port to network traffic and a 2nd port for iSCSI communication with a NAS on my home file servers.

12Dec/100

Set G-mail to be OSX default ‘Email Reader’

I wish I had known about the Gmail Notifier for OSX earlier.  I have wanted the ability to set OSX's default email read app to G-mail (via a web browser) for sometime.  I had been using a Firefox extension for years which resolved most 'mail-to' link issues; however, it never resolved applications trying to send e-mails.  Since switching to Google Crome as my primary browser the OSX default 'email reader' issue has reemerged.  Thanks to Gmail Notifier I can put that issue to rest.  I was pleased to see that the Gmail Notifier app respects your preferred browser settings and has lots of setting that you can tweak.  Plus, you can't beat the fact that it's free.  Thanks Google.

Filed under: Uncategorized No Comments
8Dec/105

OSX MusicIP 1.8 Headless Walk-through

Description

MusicIP is a music service that provides functionality much like iTunes Genius Mix. I personally utilize MusicIP for my Squeezebox Server. This is a walk-though of how to get the MusicIP headless client to run on OSX. Presently there is no official support for this software and the documentation is out of date or just wrong for OSX users. Getting the headless client to run is a pretty simple fix but requires that you do some tinkering. I am using OSX Server 10.5 but this walk-though should work on any version of OSX, including the non-server version of OSX.

Background

After a lot of research, Googling and poking around I determined that the documented way of getting MusicIP to startup doesn't work. Luckily, in the MusicIP Mixer Application package there is an app named: 'MusicMagicHeadless'. Running this app from command line will throw some errors but it does run and you can then access your MusicIP data without having a user logged in. All we need to do is make OSX launch this headless application on startup and setup the data so that the root account has access to your MusicIP data. So let's start.

Warning: I am not responsible for any damage that you do to your system. This walk-through requires utilizing the 'root' account so be careful.

Instructions:

Download MusicIP

This tutorial assumes that you install the MusicIP Mixer App in the main Applications folder and that you have already run the MusicIP Mixer App and have scanned you music collection. Currently you can download MusicIP Mixer version 1.8 from the following site: Amplifind Music Services. You will continue to use the MusicIP Mixer App to scan any new music or make changes to your settings. The headless client will provide the MusicIP API service so that other programs like the SqueezeBox Server can retrieve your MusicIP data via port 10002 (or your custom port). Make sure to note what User Account you are using when running the MusicIP Mixer. You should always make sure to use the same account in the future when updating your MusicIP data.

Making a MusicIP a startup item

Download the attached MusicIP.zip file to your computer and extract the 'MusicIP' folder within. The MusicIP folder has two simple text files within that tell OSX to start a headless program at boot. If you would like to learn more about startup items in OSX then check out this link.

Next, move this ‘MusicIP’ folder, via Finder or Console, to the following location:

/Library/StartupItems/

OSX will ask you for the administrator password as this is a system location. Make sure that you moved these files to the main 'Library' folder in "Macintosh HD", and NOT in a user Library folder.

Note: The MusicIP startup script assumes that you have MusicIP 1.8 installed in the standard ‘/Applications’ folder. If you have the app in a different folder or user's Application folder, the you will need to update the path in the startup script or move the MusicIp app to the standard location.

At this point if you reboot the machine you will see that the MusicIP headless client will try to start; however, MusicIP will still be missing it’s data. There is a good chance that you will get prompted with a System popup stating that the MusicIP file does not have the correct permission. If you see this window click 'Repair' to have OSX give the file the correct permissions.

Mapping your MusicIP data

Background

Startup apps that run at boot will be executed by the ‘root’ user account. The problem is that when the headless MusicIP client runs it looks in the current users Library for the MusicIP database; however, root has no MusicIP data thus the app has nothing to serve. We are going setup up a link that will point from the root user account to your main user account's MusicIP data. This way we can have our headless client run at boot, via the root account, but have it use your user account's MusicIP database. This also let's you update your MusicIP data with the standard MusicIP Mixer app, via your user account, and not have to worry about copying or syncing data in the future or unnecessary root tinkering.

Verify you MusicIP data

Lets first verify your MusicIP data by using the Terminal App. Most OSX Apps store your user setting in the following folder: “[YourUserPath]/Library/Application Support”. Inside of that folder there should be a ‘MusicMagic’ folder which contains all the settings and data for MusicIP. The way to access this in Terminal is by typing the following:

cd ~/Library/Application\ Support/MusicMagic/

Once inside this folder you should see 4 items. Type the following to see the list of items in this folder.

ls

You should see something like the following:

If you see these files you are in great shape, if not then you might want to double check that you are looking in the correct ‘Library’ folder and that you have run MusicIP Mixer and/or scanned some music.

Modifying the Root Account data

In this step we are going to create a Symbolic Link which link the root accounts MusicIP data to your current users accounts MusicMagic settings.

You should be logged into the account that has run the MusicIP App. Run the following command to create the symlink.

sudo ln -s ~/Library/Application\ Support/MusicMagic /var/root/Library/Application\ Support/MusicMagic

You will be prompted for the root user password. Remember, the /var/root account is hidden from all users, even Admins.

You can verify the link by running the following line:

sudo ls -l /var/root/Library/Application\ Support/MusicMagic

You should see something like the following as output:

lrwxr-xr-x  1 root  wheel  52 Nov 21 13:19 /var/root/Library/Application Support/MusicMagic -> /Users/[UserName]/Library/Application Support/MusicMagic/

If you see the line above then you're doing great!

Wrap up:

At this point you should be all set. When your computer starts up it will run the MusicIP headless client as the root user. MusicIP will look in it’s current users Library to find the settings ( /var/root/Library/Application Settings/ ). It will see the ‘MusicMagic’ folder, which is actually a Symbolic Link to your Users MusicMagic data.

At anytime you will be able to update your MusicMagic database by just logging on as normal and running the Music Magic application.

Conclusion:

I hope that this is helpful. I have been running MusicMagic and my Squeezebox Server headless for the last week and it seems to be very nice and stable. To verify that your server is running, reboot it and after it has startup up try to access the MusicIP API service at:

http://localhost:10002/api

You should see the following:

Trouble Shooting

If you are having no luck getting the app to run then you can look at your system log to see what is wrong. Your system log should be located here: ‘/var/log/system.log’ /var is a hidden folder so you need to access it with the Terminal App or hit ‘CTRL - Apple - G’ in Explorer to get the ‘Go To Folder’ Popup.

Use this line for if you want to use the Terminal App:

less /var/log/system.log | grep -i "MusicMagicHeadless"

Another thing to try is log into the Root account and try running the MusicMagicHeadless client. If you can run the client but you are not seeing any data then you might have an issue related to the Symbolic Link we created. If the API is running you will be able to see your server data at localhost:10002 but when you try to look up songs you won't get any data.

22Nov/090

AS2 destructor tips

Creating an AS2 destructorFlashDestructor2

Who's this for?

This article is intended for AS2 developers using FlashLite but you can use the same principals for standard Flash Player development.  You can also apply much of this logic to ScaleForm development, but there are some special cases for ScaleForm 2.x code as it lacks Garbage Collection.  You can follow these tips if you are using ScaleForm 3.x.

Let's Start

In almost all FlashLite projects you need to create a common destructor method in Flash so that you can properly dismantle the complex objects you are creating.  In most Flash projects it's a good habit to make sure that you dismantle objects and delete them so that Flash Garbage Collection can properly delete the object to free up memory.  If you are doing performance work then you might also want to look up Object Pooling as it can be faster than deleting object and creating new ones.  I always use the method destroy() for my Flash destructors and always declare destroy() right after my constructor so it's easy to find.  A example destructor might look like this:

[code lang="as2"]
/**
* AS2 Example
**/
class exampleClass
{

// CONST's
public static var EXAMPLE:String = "example";

// member variables
public var _exampleA:String;
public var _exampleB:String;

public var _clip:MovieClip;

/**
*   your constructor
**/
public function exampleClass()
{
_exampleA = "We are setting up this data.";
_exampleB = "And this string " + EXAMPLE + " is setup as well";

_clip = this.createMovieClip( "_clip", this.getNextHighestDepth() );
}

/**
*   your destructor
**/
public function destroy():Void
{
_clip.removeMovieClip();
delete _clip;

//don't delete the static vars!
delete _exampleB;
delete _exampleA;
}

}
[/code]

Random knowledge about the delete keyword in AS2:

The AS2 method, delete, really only sets the property to null and then removes the property from the object.  It doesn’t mean the data is deleted. Garbage Collection is the only device in Flash that actually destroys data and frees up memory.  Unfortunately you cannot rely on delete in some situations.  Setting some objects to null is a common work-around in AS2 in insure that an property is no longer referencing an object.  It's important to force Flash to set items like onEnterFrame to null in case delete does fail.

Technically you don’t need to use delete.  You could just set all of your items to null though there are some advantages when debugging.  I personally use delete because it helps figure out what objects aren’t being deleted.  For debugging purposes you can always traverse through this or with a for loop and look for offending objects.  If we didn’t delete the properties you would have more items to inspect as each property will still exist, they will just be set to null.  Remember that any objects that exist in your FLA can't be deleted at run-time, they won't go away until you have fully de-referenced all of the object and unloaded that swf file.

Why deleting objects can help performance

The main reason for deleting all the objects you created in a class is that you are helping Flash figure out what objects should be destroyed.  Flash uses 2 types of Garbage Collection and the core way it figures out what to delete is to look at the reference count.  By removing all the references in your destructor you can save Flash from performing the same work.  In addition, it can take multiple passes for Flash to get the reference count down to zero, again your destructor can do this process much faster then Flash.  FlashLite runs the “garbage collector (GC) once every 60 seconds or whenever usage of memory increases suddenly by 20% or more” (Adobe).  So if you let Flash dismantle your object it can take a couple minutes for it to slowly take the object apart until the reference count is 0.  That means your .swf can be using up valuable RAM for 2 or 3 minutes more than it should.  FlashLite 3.0 DOES support Mark-and-Sweep which can speed up GC, but you still want to give FlashLite a helping hand.

Finally, this is a valuable skill to have even if you don't do FlashLite work.  Now that many website host Flash Apps it rather important to keep your memory usage in check as users do not reload you SWF very often.  In addition, Flash Games rarely are reloaded to these too need to keep their memory usage in check.  As a Flash Developer it's a good idea to be knowledgeable of how your Flash content is handling both it's memory allocation as well as making sure you are doing your part assisting Flash deallocate memory as well.

Some AS2 destructor tips:

  1. If you are inheriting the class don’t forget your super.destroy(); when used, make sure it’s the LAST item in your destroy method.
  2. Typically you want your destroy() to be the inverse of your constructor.  So the first variable you created is usually the 2nd to last variable in your destructor (see above).
  3. Don't delete your static variables!  For some reason Flash does not re-create them if you reload the .swf and you'll get weird errors.
  4. Functions and references to other MovieClips or TextFields are best set to null before you delete them.
  5. onEnterFrame if used MUST be set to null in destructor
  6. Clear ALL the intervals in your destructor even if they shouldn’t logically be running.  Assume they are.
  7. If you have Arrays or Objects holding data, pop() all of the elements out and destroy/delete them.  When the Array is empty delete it.
  8. If you dynamically created a MovieClip or a TextField you should remove it using their specific Flash remove methods (ie removeMovieClip() ).  References to a Movieclip only need to be set to null.
  9. “delete this;” does nothing, the parent object needs to delete it

References:

Tagged as: , No Comments
9Nov/090

Locking down OSX Server 10.6 ( with the standard SSH port )

Disclaimer!

Warning: Double check all your steps in this next section or you can easily lock yourself out of your server!  If it's off-site the only way to fix the issue is with a Physical Keyboard and monitor connected to the server!  I take no reponsibility if you lock youself out of your machine.  Please don't skip the steps in this tutorial.

Before we start

You will be required to use SSH Tunneling in this tutorial so if you do not know how to do this then read the Using OSX’s default Screen Sharing tool though a secure SSH tunnel post first.  If you have finished the SSH Tunneling Screen Sharing posts then I highly recommend the Custom Port setup to avoid brute force attacks on your server.  If you do NOT want to use custom SSH port and WANT to use the standard SSH port (22) then this is the CORRECT tutorial for you.  If you want to use Custom Ports for SSH then use this other tutorial: Locking down OSX Server 10.6 ( with a custom SSH port )

Both tutorials are very similar but I do not want there to be any confusion.  It very easy to accidentally lock yourself out of your servers.  Make sure you pick the tutorial for your setup.

Please say the following sentence out loud:

"I have a Standard SSH setup on my server that uses default SSH port 22." - You

If you agree with what you just said then continue.

Let's Start

We often want to lock down our servers to reduce their vulnerabilities.  As mentioned in the Screen Sharing post you can use SSH Tunneling to keep your server locked up pretty tight yet enjoy some of the tools that make Administering a server more enjoyable.  Firewalls are one of the best ways to lock down a server.  Firewalls exist in two forms: Hardware and Software.  OSX Server has a very nice Software firewall which is very easy to setup, but it is also very easy to lock you out of your Server.  So think before you click and don't rush.  In this tutorial I am going to assume that you have Screen Sharing enabled on the server and you are using it for this tutorial.

Connect to your server using Screen Sharing

For this first step connect to your server using the Screen Sharing tool using the default port.  Don't use an SSH tunnel yet because we are going to be setting up SSH first.  Open Screen Sharing and enter in servers location and connect to the server.

Open "Server Preferences"

Once you are on the server you will need to open "Server Preferences".  You may need to enter an administrator username and password to get access to the window. From the Server Preferences windows we are going to select the "Security" button.

ServerPreferences0

Enable the Firewall

Now for the big step.  Turn the Security toggle to "On".

ServerPreferences1

You should now see something close to the image below.  Typically the services you have setup will automatically be in the list.  The very first step is to add Screen Sharing right away.  Press the "+" button to add a service to the firewall.

ServerPreferences2

In the "Add Service" field pick "Screen Sharing" and then press the "Add" button.

ServerPreferences3

Your window should now look something like this.

ServerPreferences4

At this point you should close this window and the Firewall setting will take.  You should NOT loose your Screen Sharing connection.  Make sure to test that you can connect to your server via SSH.  After you are sure you can SSH onto the server we can proceed and close the Screen Sharing app.

Screen Sharing via SSH tunnel

Create a SSH Tunnel for Screen Sharing and re-connect to the server over the SSH tunnel.  Do NOT continue until you have the tunnel running and you are Screen Sharing through the tunnel.  This step exists to verify that you CAN tunnel into your machine!

Go back into the "Security" settings.  Now we will be removing the "Screen Sharing" option by selecting it and pressing the "-" button.  You should see something similar to the image below once the service has been removed.  You can now close this window as you have fully setup your Firewall.

ServerPreferences2

At this point you can close your Screen Sharing app. Now try to reconnect to your server WITHOUT using your SSH tunnel. Verify that yourScreen Sharing connection is rejected or fails to connect. If you can't connect over the standard port then you are all done! You just made your server even more secure.  If you want further security consider the SSH custom port or a SSH shared key setup.

Wrap up

It's very important that you NEVER remove the "Remote Login (SSH)" service from your firewall.  Without SSH you have no way to log onto the machine now that Screen Sharing is disabled.

Tagged as: , No Comments
9Nov/090

Locking down OSX Server 10.6 (with a custom SSH port)

Disclaimer!

Warning: Double check all your steps in this next section or you can easily lock yourself out of your server! If it's off-site the only way to fix the issue is with a Physical Keyboard and monitor connected to the server! I take no reponsibility if you lock youself out of your machine. Please don't skip the steps in this tutorial.

Before we start

You will be required to use SSH Tunneling in this tutorial so if you do not know how to do this then read the Using OSX’s default Screen Sharing tool though a secure SSH tunnel post first.  If you DO want to use custom SSH port then this is the CORRECT tutorial for you. If you WANT to use the standard SSH port (22) then please go to the standard SSH port tutorial: Locking down OSX Server 10.6 ( with the standard SSH port )

Both tutorials are very similar but I do not want there to be any confusion. It very easy to accidentally lock yourself out of your servers. Make sure you pick the tutorial for your setup.

Please say the following sentence out loud:

"I have a Custom SSH setup on my server that does NOT use port 22 for SSH access." - You

If you agree with what you just said then continue.

Let's Start

We often want to lock down our servers to reduce their vulnerabilities. As mentioned in the Screen Sharing post you can use SSH Tunneling to keep your server locked up pretty tight yet enjoy some of the tools that make Administering a server more enjoyable. Firewalls are one of the best ways to lock down a server. Firewalls exist in two forms: Hardware and Software. OSX Server has a very nice Software firewall which is very easy to setup, but it is also very easy to lock you out of your Server. So think before you click and don't rush. In this tutorial I am going to assume that you have Screen Sharing enabled on the server and you are using it for this tutorial.

Connect to your server using Screen Sharing

For this first step connect to your server using the Screen Sharing tool using the default port. Don't use an SSH tunnel yet because we are going to be setting up SSH first. Open Screen Sharing and enter in servers location and connect to the server.

Open "Server Preferences"

Once you are on the server you will need to open "Server Preferences". You may need to enter an administrator username and password to get access to the window. From the Server Preferences windows we are going to select the "Security" button.

ServerPreferences0

Enable the Firewall

Now for the big step. Turn the Security toggle to "On".

ServerPreferences1

You should now see something close to the image below. Typically the services you have setup will automatically be in the list. The very first step is to add Screen Sharing right away. Press the "+" button to add a service to the firewall.

ServerPreferences2

In the "Add Service" field pick "Screen Sharing" and then press the "Add" button.

ServerPreferences3

Your window should now look something like this.

ServerPreferences4

Its important to understand that the SSH port listed above is the Default port (22) not your custom port.  So let add your custom SSH port.  Press the "+" button again and this time choose "Custom" in the drop down list.  In the "Service Name:" field enter something like "Secret SSH".  In the "Port:" field enter your custom SSH port, in our case that is "27000".  Obviously enter the port that applied to your setup.  Press "Add" when you are done.

ServerPreferences5

Now your setup should look something like this.

ServerPreferences6

At this point you should close this window and the Firewall setting will take. You should NOT loose your Screen Sharing connection. Make sure to test that you can connect to your server via SSH.

After you are sure you can SSH onto the server we can re-open the "Security" window and remove the standard "Remote Login (SSH)" by selecting it and pressing the "-" button.

ServerPreferences7

Close the "Security" window and verify that can still connect via your custom SSH port.  If you are sure you can SSH onto the server then close the Screen Sharing app.

Screen Sharing via SSH tunnel

Create a SSH Tunnel for Screen Sharing and re-connect to the server over the SSH tunnel. Do NOT continue until you have the tunnel running and you are Screen Sharing through the tunnel. This step exists to verify that you CAN tunnel into your machine!

Go back into the "Security" settings. Now we will be removing the "Screen Sharing" option by selecting it and pressing the "-" button. You should see something similar to the image below once the service has been removed. You can now close this window as you have fully setup your Firewall.

ServerPreferences8

At this point you can close your Screen Sharing app. Now try to reconnect to your server WITHOUT using your SSH tunnel. Verify that your Screen Sharing connection is rejected or fails to connect. If you can't connect over the standard port then you are all done! You just made your server even more secure.

Wrap up

It's very important that you NEVER remove the "Secret SSH" service from your firewall. Without SSH you have no way to log onto the machine now that Screen Sharing is disabled.

Tagged as: , No Comments
8Nov/090

Using OSX’s default Screen Sharing tool though a secure SSH tunnel

The GUI is one of the best parts of OSX Server. While its good to know Command Line on any server the GUI is a lot of what you are paying for in OSX Server. There are other posts about using VNC with SSH tunnels but I wanted to write a tutorial that assumes you just want to use the existing Screen Sharing feature in OSX and set up an OSX Server. In this case I will be setting up Snow Leopard Server ( OSX Server 10.6 ). The goal is that by the end of this tutorial you will hopefully understand how to create a SSH tunnel to your server and then Screen Share though that tunnel. This means that you can set your Servers Firewall to only allow SSH, thus having a very tight security.

Background:

SSH is a secure way to connect to a computer and grant access to command line. Wikipedia can provide more details about SSH. You may be familiar with using SSH to access a computer's shell (aka Command Line/ Terminal /etc.) However, you can also tunnel data though SSH to that remote computer. You can then close the Screen Sharing port on a Servers Firewall so that no outside users can access that data yet you can Tunnel into the server via SSH and use the service on your server. I highly recommend reading my other tutorial about how to lock down your SSH on your OSX server. This tutorial works with Shared keys and/or custom SSH ports. I'd suggest using both and setting them up on you server and then returning to this tutorial.

Screen Sharing is Mac's special brand of VPN though I won't get in to the details about how it's different. Apple has taken some precautions to make it more secure and there are options in the Screen Sharing app to "Encrypt all network data". However, allowing Screen Sharing enabled means that you still have a port that will most likely be attacked by hackers on your server. What is important to note is that the default port for Screen Sharing is 5900.

TOOLS:

You will need 3 things handy: the Terminal App, Screen Sharing App, and JellyfiSSH App. Let's quickly walk though these.

TerminalTerminal App

If you don't know this app then this tutorial might be a little advanced for you. Continue at your own risk. I recommend putting Terminal in your Dock if you haven't done so already.

Screen SharingScreen Sharing App

The Screen sharing app is hidden at this path in OSX:

/System/Library/CoreServices/Screen Sharing

You should find the file in Finder and add it to your Dock.

JellyfiSSHJellyfiSSH App

This is the only app that isn't included with OSX. It's free and can be downloaded here at the [MWorks] sites. We will be utilizing their SSH tunneling setup. More or less it's a GUI tool to simplify SSH. You can setup SSH to be extra verbose and it will show you exactly what SSH flags they are handing to the SSH app.

Setup:

Pick a port

Let's take a quick look at all the Ports that OSX uses. We are going to want to pick one to use on our local machine that will be forwarded to the remote Server. Run the following line in Terminal:

cat /etc/services

You should see something like this:

cat services

The part to look for are values that have "Unassigned" next to the number. For instance 48557-49150. For this SSH tunneling example you just want to pick a port that is easy to remember, for this example I am going to use port 49000.

Setup JellyfiSSH

Open JellyfiSSH and click the "New" button on the bottom left.

JellyfiSSH Setup 0

Now enter the Bookmark Title which is just the name that will appear on your bookmark. Enter the hostname or IP of your Server in the "Host or IP" text field. If you have a custom port enter that in the "Port" field. "Login name" should be your username on the server. All the other settings are good in their Defaults and shouldn't be changed unless you know better.

JellyfiSSH Setup 1

Now lets press the "SSH Option" button on the top of the screen.

JellyfiSSH Setup 2

We're not touching anything on this screen but we click the "Define Tunnels..." button to access the tunnel setup screen. In the "Name" field you will enter a name for your tunnel. I just used "Screen Sharing" to be clear on what we data we are tunneling. The "Remote Port" is the address on the server where we want to send the data so we'll set that to 5900. The Remote Host is the server name or IP of the server. Finally the "Local Port" is going to be the port that you picked out earlier, so for this example we are using 49000. Make sure to click the "Add" button when you are complete then "Save Changes".

JellyfiSSH Setup 3

You will be presented with a Modify Changes dialog. After you press "OK" it will kick you back to the main JellyfiSSH screen.

Start your Tunnel

Make sure that your site is selected as the "Bookmark" and then press connect.

JellyfiSSH Connected

Hopefully you see something like the screen above. I have blurred out some fields for privacy. But you can see that JellyfiSSH is just taking the data and plugging it into Terminal. If you have never connected to the site via SSH you might need to accept the SSH Key. If you have have an SSH Key with a Passphrase you will need to enter it. But the good news is your SSH tunnel is working! Leave the terminal window open if you want to keep the tunnel open, but you can close JellyfiSSH if you like.

Recap

So what you've now done is made a port (49000) on your local machine that tunnels traffic to that port through your secure SSH session to your remote server and that data will arrive at port (5900) on the remote server. Now your Screen Sharing data is traveling over the internet in a very secure format and can not be deciphered by evil parties on the web.

Let's Screen Share Securely

Now for the fun part. Open the "Screen Sharing" app on your computer. We are going to connect to your local computer but use that custom port we setup. So enter "localhost:49000" into the "Host:" field. (Alternatively you can also use "127.0.0.1:49000" which seems to resolve faster for me. ) Then click "Connect".

Screen Sharing 0

Drum roll....

Screen Sharing 1

And voilà! You are connecting to your server. Even thought it says "Localhost" in the prompt you are actually communicating with the remote server. Now enter your login information for the server and you are successfully screen sharing without worrying about security!

Screen Sharing 2

When you are done just close Screen Sharing and remember to close your Terminal windows to close the tunnel.

That wraps up using VPN Tunnels with Screen Sharing. However using a secure tunnel is most useful if you enable the firewall on you OSX Server. I have broken down these steps in two other posts depending on your server setup:

If you have a default SSH setup (port 22) use this tutorial:

Locking down OSX Server 10.6 ( with the standard SSH port )

If you have a custom SSH setup use this tutorial:

Locking down OSX Server 10.6 ( with a custom SSH port )

Resources:

1Nov/090

How to disable Bonjour for OSX 10.6

BonjourMuteButtonSimply put there are times when you just don't want OSX to broadcast it's Bonjour information over your local network.  Maybe you are in a dorm and don't want people trying to access your shares, maybe you have an OSX Server in a Collocation facility and don't want other computers to know you exist.  All in all, there are times where you don't want to announce your presence for whatever reason.

If you are unlucky you might have already learned that some older Bonjour disabling work-arounds for OSX 10.4 and OSX 10.5 will cause things to break in OSX 10.6.  Typically the problem you will see is that DNS fails to run, which makes the internet not fun at all.

Luckily there is an official article where Apple explains how one would disable Bonjour yet keep DNS working.  I think it's a poorly named article thus making it difficult to Google.  This fix is for OSX 10.6 (Snow Leopard) and OSX Server 10.6 (Snow Leopard Server)... The fix is very simple and it's working great on my server.

Mac OS X v10.6: Disabling mDNSResponder will disable DNS

Tagged as: No Comments
17Oct/090

DTerm

DTerm128DTerm, A command line anywhere and everywhere
Despite being swamped with work I came across a tool that I just had to plug. DTerm is a small OSX application that let's you open a Terminal Panel in from any windows in OSX via a keyboard shortcut. It lets you have all the ease and power of your GUI yet have terminal at your finger-tips instantly.

It's awesome because you never have to leave the focus of the task you are doing which can help keep you focused and save time.  If your following a web tutorial walking you through setting up GIT you can do all of the required command line calls without never having to leave your browser.

You can also have DTerm send the commands a new Terminal window if your realize that you might need to do more work at command line.  It's a heavenly tool for anyone that uses OSX and does a lot of command line work.  Check out the video of DTerm on the Decimus Software website. Best of all Its Free!

Filed under: Uncategorized No Comments
porno porn