Sc@-tt3r-ed Thoughts

A few days ago,  I posted an article about creating a hidden share on a Mac server. Well, apparently, with Apple, from version 10.5.8 to version 10.6.x, the way things work actually changed. What a shocker! ok.. sarcasm aside.. Here’s what happened.

In OS 10.5.8, there used to be a file in /var/samba/shares, that can be renamed with a “$” sign in the end, to make an existing share hidden.

In OS 10.6.2 and above, that “shares” directory just disappeared, and therefore my idea about creating hidden shares with this method became obsolete.

So, I went back out there googling for a solution. Unfortunately, not at a single forum I went, did I find any one dealing with this issue. (strange?), so I started digging in Samba documents in order to see if I can somehow have a workaround in the Samba configuration to allow the hidden shares to show up.

Here’s what I found:

Samba, in Snow Leopard, keeps its configuration in /var/db/samba. The file is that is of interest, is the /var/db/samba/smb.shares. In Traditional configurations of Samba, these shares get their configs from smb.conf, however, in this situation, smb.shares is the file needed.

So, let’s put down the scenario I was in and how I resolved it:

The Snow Leopard server was the SMB server for home folders, for both Mac workstations, as well as Windows workstations. The home folders for the Mac was at the following path: /Volumes/StudentData/User/Students

The SMB share from within the OS X GUI was pointing exactly at that path, and was shared as a non-hidden share called: Students. When creating the Mac home folders, this is the path that gets looked at, and gets the users’ home folder. Thats a no brainer. However, when Windows workstations need to map the home directory, they need a different path, mostly because my Windows infrastructure is standardized to the format of: \\servername\user$\students.

From the GUI, as far as I know, it’s impossible to create a separate share point to the same physical path. However, in SMB it’s possible. Unfortunately, this was not the only challenge, because, even if it was possible to create multiple share points within the GUI, there is no way to make it a hidden share.

So the idea is to create a config file in SMB that will do what we need.

Caution: The file we’re going to change is going to have a warning on top that says: # This file is automatically generated, DO NOT EDIT!  . This is nothing to worry about it in this case, as long as you are aware that this statement is actually TRUE! meaning, if you go back to the GUI, and modify any of the shares, this file is going to revert to its default, overwriting any changes you made outside of the GUI. So consider yourself warned, and make sure that you keep your changes somewhere that you can restore after you make modifications to GUI share points. 

Edit the file: /var/db/samba/smb.shares

For the configuration above, the file would look something like this:

#
# Configuration options for smbd(8), nmbd(8) and winbindd(8).
#
# This file is automatically generated, DO NOT EDIT!
#
[Students]
comment = Students
path = /Volumes/StudentData/User$/Students

available = yes
guest ok = yes
inherit permissions = yes
create mask = 0644
directory mask = 0755
oplocks = yes
strict locking = 1
read only = no
Browseable = yes
[global]

In order to add the hidden share to be accessible via \\servername\user$
we’ll add the following section, before the [global] section.

[User$]
comment = Users
path = /Volumes/StudentData/User$
available = yes
guest ok = yes
inherit permissions = yes
create mask = 0644
directory mask = 0755
oplocks = yes
strict locking = 1
read only = no
Browseable = no

[global]

What we have effectively done in this case, is create a share that is non-browseable for Samba (by setting the “Browseable = no” argument.), and naming the share User$, which is what Windows refers to hidden shares as. By combining the way both OS’s understand hidden shares, we have satisfied all the requirements needed or both Mac home folders, as well as PC shares, that no longer have to comply with the exact nomenclature that OS X pins us down to. (Take that Apple!!)
Make sure to restart SMB on the OS X server anytime you make change.

A couple of days ago, I was dealing with the issue of trying to have home directories residing on Mac servers where the users would connect to these home directories which are auto created from their Mac workstations, but also, need these same home directories to be available for mapping via login script to the Windows clients.

The problem that I was faced with, which also matches my philosophy about security, was that everywhere else where I had created shares, I had them setup as hidden shares. Something makes me uneasy knowing that users would be able to just browse all shares (Even though they can’t really access them) if the shares are not hidden.

So, in all my Windows environments, where user data is on Windows shares, the path looks something like this:

D:\User\Students\%USERNAME% with a share point physically pointing to D:\User, and named user$, so the path to the user’s home directory from a UNC perspective would look like this:

\\servername\user$\students\%USERNAME%

Can you guess where the problem is on a Mac, trying to create the same type of share?

\\servername\user$\students\%USERNAME%

From my research, it doesn’t seem like it’s even possible to create a hidden share from Mac OS X Server, at least not natively. I have tried everything, from changing the name of the share to have a “$” sign in it, to changing the share name in the SMB protocol options. Non worked, or returned the expected result.

The solution ended up being a hack, it’s not permanent, as it will revert back to non hidden state if any changes are made to that share point, but, realistically speaking, once a share is created, it’s permanently there, or at least long term.

To make a share hidden on a Mac, so that Windows can access it, create the Mac share , and enable the SMB protocol, and specify the name of the share. To be consistent with the above example, we’ll name the sharepoint: “user”

Once the share is created, and all the ACLs are set, open up Terminal, and su – to root

then: cd /var/samba/shares

The share we just created above will show up in that directory, just rename that to user$:

mv user user$

Now, try to access the share like you would from Windows: \\servername\user$\students\%USERNAME%

You will notice that you are now able to do so without any problems.

Of course, this article is only explaining how to create a share, and not how to properly configure Samba. There is additional details that you need to be aware of when configuring Samba, mostly related to user authentication, especially, if the Macs are not authenticating to a common directory.  This article can give a bit of an insight on how that works: http://www.samba.org/samba/docs/using_samba/appf.html

Today, I was working on creating a script that updates some of our Student Information System core files on some workstations, and since my whole environment is based on VMWare View, I had to find a way to get the constantly changing VM numbers to be reported to the script which is supposed to update these files.

My method was to write a PowerShell script using the vSphere PowerCLI tools to get all my VMs and format them to get the total number of powered on VMs in a specific resource pool, as well as which workstations are actually available.

(Since I’m using VMWare View in a non-peristent pool, and having the VMs destroyed after the first log off, it’s hard to keep track what is on, and off, and the sequence of the workstation names is not necessarily always in order. )

Well, the script was simple:

   1:  Add-PSSnapin VMware.VimAutomation.Core

   2:  Connect-VIServer -Server do-vsphere

   3:  Get-ResourcePool "Aeries View Devel" | Get-VM | grep -c -i "AeriesCS-SB-*" \

   4:  | Out-File "\\do-tech\vmlogs$\AeriesVMCount.txt"

   5:  $VMArray = Get-ResourcePool "Aeries View Devel" | Get-VM | grep -i "AeriesCS-SB*" |sort

   6:  

   7:  foreach ($VM in $VMArray)

   8:  {

   9:      $VM = $VM.substring(0, 15)

  10:      $VM = $VM.substring($VM.Length - 3, 3)

  11:      $VM | Out-File -append "\\do-tech\vmlogs$\AeriesVMCount.txt"

  12:  }

In opening the results of this file in a KIXtart script, the results were very sporadic, having weird characters, and never returned the expected data. By the way, The ‘Out-File’ in its current form above seems to have the same output effect as a regular DOS redirect command, within the Powershell environment: i.e: $VM > “\\do-tech\vmlogs$\AeriesVMCount.txt”

Since there is no point in listing all the different things I have done, I will tell you exactly what the problem is in this scenario:

Out-File apparently does not, by default output text in ASCII encoding, and therefore, the resulting text is usually un-interpretable by other scripts. In order to fix this, a small modification to the Out-File command would be required, so line 11 would look like this:

$VM | Out-File - append "\\do-tech\vmlogs$\AeriesVMCount.txt" -encoding ASCII

Adding this small addition to the Out-File resolved the problem of incorrect encoding. I spent about 3 hours trying to figure out why my redirection weren’t working until I found the solution. So hopefully this will help someone who is a PowerShell novice like me, who may face the same problem.

The question of calendar syncing has been quite a big one on the forums on the net. I was also one that has a problem figuring out how to sync all my calendars, and I kept doing more research and experimentation until I finally found perfect solution that seems to work across the board. That is what you’re here for right?

Alright, in this blog entry, I’m going to try to give as much detail as I can based on the scenario that I have in my calendars, as I think my situation covers in part or in all, most other people’s situations. From these different steps, you can take any part you want, and apply it to your particular setup to get what you need.

So let’s get started. I’m going to describe everything based on the setup that I currently have running. This involves: iCal, gCAL, Outlook, and 3rd party calendars, including shared Google calendars, and Tungle meeting organizer.  Now before we continue, let me put in a warning before starting:

The process you’re about to see requires performing major surgery on your calendars. There is no scripting, or crazy techy stuff involved, but you have to be methodical to make this whole thing work.

.. continue reading ..

I’m in the process of trying to get rid of any thick clients that I currently work on to convert solely to Virtual Machines, and clear out my desk space.
Well, I thought the best way to do this was to move my Precision 690 to the lab, install ESXi on it, and have a my VM on there.

As I tried to add the VM that resides on this ESXi server (which is not part of vCenter), I could not add it as an individual desktop.  I then remembered that I needed to have the View agent installed for this to work. After installing the View Agent, I was hopeful, but alas, the VM still didn’t show up. On Step 3 of adding the machine, it would supposedly give a list of available VMs to add and a find option, but nothing could be found. .. continue reading ..

So, here I am sitting at my office trying to get VMWare View to work on an HP T5540 thin client. Had no idea where to get the client for. the 11Mb file that you get from VMWare is entirely too big to be intalled on that client. This is a Win CE operating system, which is so horrible to deal with anyway.

Google searches failed me left and right, everywhere I looked. People said that the T5540 can only be used in a remote desktop environment, which, of course, will lose out on the capability of VDI, dynamic provisioning, multiple desktop availability, Multimedia, and USB. Essentially, all the advantages of VDI would’ve gone down the drain. so that was not an option for me.

Some mentioned JRE version for Win CE, on which the VDI client will run. I had 2 problems with this one:

1. I couldn’t easily find a free JRE client for WinCE
2. For the life of me, I could not figure out how to get VDI Manager to use JRE.

So, I went ahead with my research, until I stumbled upon something called the VDI Broker Add-On for Microsoft Windows CE.  That can be found here: http://bit.ly/16M38p

If you look closely at the description of this download, however, you will find that it says this:

"This is an Altiris package that contains the VDM Broker Agent for the supported thin client models running a supported operating system.”

Hmm.. I thought I’d try it anyway. Downloading the file wasn’t a problem. Running the file, however, was. It just plain wouldn’t run from the T5540.

So poking around some more, I finally got the solution. Unzip the EXE that is supposedly designed for Altiris, and you will find a little file (145Kb)  called VDMClient.cab, which will do the trick. Now, copy this to your T5540, and run it, and you shall have your VDI client available.

This took me about an hour of research to figure out, since there is absolutely no documentation I could find about it anywhere!. 

Hopefully this will help someone that may be having the same problem.