Forum Replies Created
-
AuthorPosts
-
October 10, 2012 at 12:37 am in reply to: InstaDMG on 10.8.2, BaseImageCache and Recovery HD #384434
kai
ParticipantThanks 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.kai
ParticipantPhew, 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,
Kaikai
ParticipantOK, 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…
August 31, 2010 at 11:30 pm in reply to: InstaDMG installing Growl opens Boot Machine’s System Prefs #379372kai
ParticipantJust 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]
March 22, 2010 at 3:25 am in reply to: Using VPN provided DNS Servers on Snow Leopard built-in PPTP VPN Client #378247kai
ParticipantHere’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]February 27, 2010 at 9:25 pm in reply to: Using VPN provided DNS Servers on Snow Leopard built-in PPTP VPN Client #378093kai
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 53I 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…
February 27, 2010 at 3:28 am in reply to: Using VPN provided DNS Servers on Snow Leopard built-in PPTP VPN Client #378089kai
ParticipantI’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.
-
AuthorPosts
Recent Comments