Forum Replies Created

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • in reply to: InstaDMG on 10.8.2, BaseImageCache and Recovery HD #384434
    kai
    Participant

    Thanks again for the update – seems to work well here now I’ve had a chance to test it.
    It runs and correctly identifies that there’s a recovery partition present and then goes on it’s way and installs things properly again.

    in reply to: InstaDMG on 10.8.2, BaseImageCache and Recovery HD #384431
    kai
    Participant

    Phew, glad to see I wasn’t imagining things – it was a long day… Keen to get the updated svn version, thank you very much for getting on the case so quickly.

    Cheers,
    Kai

    in reply to: InstaDMG on 10.8.2, BaseImageCache and Recovery HD #384429
    kai
    Participant

    OK, now I don’t know what’s going on (it’s late on a Friday, that’s mu excuse)
    I had a hack and slash on the bash script (or thought I did) and re-ran it, and now it’s working as expected. As it turns out however, I was working on a copy of the script, not the main one. So, now it’s running properly.

    I can’t explain what’s happening, why it didn’t work and now why it is working – but it’d be good for someone with better bash-fu than me to look at the script and make sure it’s properly dealing with two mountable partitions in the base image…

    kai
    Participant

    Just in case anyone is struggling with this still – Growl is now a flat package, so not as straightforward to edit. Here’s how to expand it, edit it and put it all back together again:

    Download the Growl package and then in the Terminal:

    [code]pkgutil –expand Growl.pkg Growl[/code]

    Next, edit Growl/growl.pkg/Scripts/postflight and change it to the following (add the first and last lines)

    [b]if [ “$3” = “/” ]; then[/b]
    # Open GHA first so that, hopefully, Growl will already be running when the user lands in the prefpane.
    “${PACKAGE_RESOURCES_DIR}/OpenAppWithoutAddingToRecents” “${INSTALL_DESTINATION_DIR}/Growl.prefPane/Contents/Resources/GrowlHelperApp.app”
    “${PACKAGE_RESOURCES_DIR}/OpenGrowlPrefPane”
    [b]fi[/b]

    Finally, put it all back together again

    [code]pkgutil –flatten Growl Growl121.pkg[/code]

    kai
    Participant

    Here’s what I’ve found with the testing that I’ve done.

    Mac OS X 10.5.x – works as expected. VPN supplied DNS servers are queried by the system.

    Mac OS X 10.6.2 – DNS servers supplied by the VPN are not queried, unless the VPN service is the highest priority network service, in which case they are exclusively used. In addition, if the VPN is the highest service listed in System Preferences, all internet traffic is passed over the VPN.

    Mac OS X 10.6.2 with entries in /etc/resolver – the entries in /etc/resolver are used by some utilities, including most of the system level DNS lookups. They are specifically not used by the host, dig or nslookup commands. If you, for instance, ping a server, it is able to have it’s name resolved.

    I have created an AppleScript that makes it easy for me to distribute these settings to end users that are not using an SOE.

    [code]set theDomainName to “example.internal”
    set theNameServer to “10.0.10.10”

    do shell script ”
    if [ ! -d /etc/resolver ]; then
    mkdir /etc/resolver
    chown root:wheel /etc/resolver
    chmod 755 resolver
    fi
    echo \”nameserver ” & theNameServer & ”
    domain ” & theDomainName & ”
    port 53\” > /etc/resolver/” & theDomainName & ”
    ” with administrator privileges
    display dialog “DNS Configuration Updated.”
    [/code]

    kai
    Participant

    [QUOTE][u]Quote by: khiltd[/u][p][QUOTE]Under 10.6, I can see in the Network preferences that the VPN network interface has received the correct DNS server as it’s listed in grey, however the machine simply will not use it.[/p][/QUOTE]

    If the +trace option of dig confirms this, then I’d say try another client like VPNTracker. [/p][/QUOTE]

    Well, when I connect to the VPN under 10.5, I can confirm that the DNS servers are correctly added to /etc/resolv.conf

    When I connect to the VPN under 10.6, the DNS servers are not added to /etc/resolv.conf

    It now seems that having a file in /etc/resolver/example.com is working for some tools, but not others.

    If I run, say, host or dig, they are unable to look up server.example.com

    If I ping server.example.com or go to http://server.example.com in Safari, it works. I can also connect to the server by name in the finder.

    This is with a file /etc/resolver/example.com with the contents:
    nameserver 10.0.1.10
    domain example.com
    port 53

    I do find it strange that name resolution on Mac OS X can happen in a few different ways, and that host and dig don’t query the hosts file – it seems that they don’t query the resolver files either.

    I don’t want to use VPN tracker as I try to minimise the use of 3rd party software wherever possible, and like to keep things as simple as possible for my clients…

    kai
    Participant

    I’m connecting to a McAfee UTM SG310 or SG560 (Used to be Secure Computing, they were bought by McAfee)

    The reason I’m doing it this way is that these units have proven to be more reliable than the VPN server in Mac OS X, and when connected to a VPN hosted by the firewall, I can reboot the server in question without getting dropped off the VPN.

    This configuration works perfectly with Mac OS X 10.5.x – I receive the DNS server from the VPN and the machine uses it if the VPN service is at the top of the list in the Network preferences. If it’s not, then my machine keeps using whatever DNS server it had prior to connecting to the VPN.

    Under 10.6, I can see in the Network preferences that the VPN network interface has received the correct DNS server as it’s listed in grey, however the machine simply will not use it.

Viewing 7 posts - 1 through 7 (of 7 total)