Posted: August 26, 2012 | Author: Kyle Crawford | Filed under: Deployment, Mac OS X, Scripting, Uncategorized | Tags: automatically, bash, force, install, kcpassword, login, mac, osx, package, pkg, script, user |
Once in a while you run into a package or program that will only work properly with a user logged in. This can ruin your day if you need to automated the deployment.
I found this method of automatically logging in a user (which is quite awesome).
Using that perl script along with a wrapper script can enable you to automate these can other cases where your only option is to have a user logged in.
I started writing a script to handle this, but it turned out I didn’t need it. The script is unfinished, but it may give you a head start if you are considering something similar.
It depends on a modified version of the perl script that accepts a username and password. Just swap out the user and password lines with these that accept arguments.
my $user = $ARGV[0];
my $pass = $ARGV[1];
and I comment out the line to automatically restarts the loginwindow.
#system(‘killall’,'loginwindow’);
Posted: November 30, 2011 | Author: Kyle Crawford | Filed under: Cocoa, Mac OS X, Security | Tags: app delegate, cocoa, explore, f-script, fscript, mac, menu, objective c, password, runtime, security |
Objective C is a Dynamic Runtime, so you can load code like plugins during runtime. This dynamic runtime can be very useful for exploring what applications are doing. I use this to assess the security of applications for example.
F-Script provides an easy way to inject itself into a running app and explore around.
Download F-Script here
Launch the app you want to explore.
Then find the process id number of the app in a Terminal shell:
ps auxww | grep “App Name“
Load the F-Script Framework into the app and insert its menu using:
sudo gdb --pid AppNameProcessID --batch --nx --command=/dev/stdin << EOT
p (char)[[NSBundle bundleWithPath:@"path/to/Library/Frameworks/FScript.framework"] load]
p (void)[FScriptMenuItem insertInMainMenu]
EOT
I found the above snippet by reviewing this automator service.
Note that sudo is only required if you are not in the _developer group.
At this point, switch to your running application. You will notice an F-Script Menu is added to the menu bar.
Choose Console from the F-Script menu and type:
del := NSApplication sharedApplication delegate
This will give you a reference to the application delegate. The application delegate is a top level class of the application, so it should provide a good starting point.
Next, choose Open Object Browser from the F-Script menu.
Now you should have a nice GUI window to explore the app.
Click on del in the Workspace to explore the app delegate. You can call methods, change values, etc.
See the F-Script documentation for more details.
Enjoy
Posted: August 6, 2008 | Author: Kyle Crawford | Filed under: Active Directory, Deployment, Mac OS X, Scripting, Unix | Tags: 10.5, Active Directory, AD plugin, DirectoryService, dsconfigad, ldapsearch, mac, replication, search domain, sites, troubleshooting, unjoined |
I was getting random AD plugin connection issues after joining to Active Directory. dsconfigad showed no errors, but sometimes I would not get a connection and I would have to rejoin. The problem turned out to be related to replication.
The AD plugin initially has no knowledge of which AD site and domain controllers are considered local to your subnet, so it discovers any domain controllers and contacts one to lookup the site information. During this process, and in general, the AD Plugin keeps an LDAP connection open to the domain controller. The AD plugin likes to reuse these LDAP connections, presumably for performance reasons. When it is time to actually add the computer to the domain, the AD Plugin reuses this existing connection. The problem is that this domain controller is not necessarily one within your AD site.
At this point, if the Mac is restarted or DirectoryService is killed, any new connections will be made to a DC in the subnet’s AD site, but if your computer was added to a non-local DC, the local DCs may have no knowledge of your computer because the computer account has not yet replicated to them.
This problem can appear to be quite random because sometimes you’ll get lucky and get a local DC for the join, or you might catch the replication at the right time. You might also see bad password errors in the DirectoryService debug logs. I have filed a bug report on this, and I don’t have a good workaround for now other than — don’t reboot or restart DirectoryService after a join. Of course if you know your replication schedules, you could just wait until you are sure replication is completed.
This same issue can present itself with unjoins and rejoins.
You can see what domain controllers you are connecting to during the join using the following shell command assuming your are joining using dsconfigad:
while [ 1 ]; do if netstat -a | grep ldap| grep ESTAB; then ps auxww | grep dsconfigad | grep -v grep; date;fi; done
If you have joined, unjoined, and rejoined and think you may be seeing replication issues, compare the whenCreated attribute of the computer account on different domain controllers using ldapsearch.
ldapsearch -LLL -v -W -x -h domaincontrollerfromsite1.subdomain.forest.com -D username@subdomain.forest.com -b "OU=Computers,DC=subdomain,DC=forest,DC=com" CN=machine-join-name | grep whenCreated:
If an older out of sync computer account exists, its whenCreated date will be different from the domain controller the computer was just added to until the last join has replicated to all the servers.
Posted: June 3, 2008 | Author: Kyle Crawford | Filed under: Python | Tags: google app engine, mac, uploading |
I kept getting errors uploading to Google App Engine on Mac.
ERROR appcfg.py:1128 An unexpected error occurred. Aborting.
I run as a normal user. Apparently appcfg.py requires some elevated privileges, as running it as root uploaded without a problem.
Here is the command to run the appcfg.py inside the GoogleAppEngineLauncher app.
sudo /Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/appcfg.py update appdirectory/ --noisy -v --email username@gmail.com
Substitute your own appdirectory and username and path to the GoogleAppEngineLauncher.app.
