Rails turns on protection from CSRF Cross-Site Request Forgery by default. It can make load testing more challenging since you need to get an authenticity_token for posting form data.
More information here: http://api.rubyonrails.org/classes/ActionController/RequestForgeryProtection/ClassMethods.html
Using current record when AppleScripting FileMaker has a couple of problems. The current record can change out from under you, so by the next step in your script, you may be dealing with the wrong record. Simply storing the record result in a variable doesn’t work either because getting the result converts it to a native AppleScript list of the data from the record. Using a reference to current record suffers the same problem.
One solution is to use record IDs. I believe that record IDs are guaranteed to be static/unchanging, at least while the app is running.
To get the record ID for the current record:
set recID to ID of current record
To use the record ID later in your script:
get cell "my_field" of record ID recID
To get all record IDs for a given query:
set recordIDs to ID of every record whose cell "my_field" is "my_value"
Then access each found record by ID:
repeat with recID in recordIDs
get cell "my_other_field" of record ID recID
end repeat
Note: The following method will also work for certain use cases since it appears to use the record ID internally as well:
set x to current record as reference
Ruby’s built-in telnet capability has been extremely useful for scripting automated RAID changes like LUN masking, etc.
It is super simple. Connect, login, issue commands, read and parse results.
The example code I used is here.
This is telnet, so don’t do this if eavesdropping is a concern.
If your firewire hard drive is failing intermittently or after transferring some data, it could be a heat issue. Symptoms might include i/o errors and spontaneous disconnects.
Simply removing the case (housing) from my Western Digital MyBook drive allowed it to work reliably enough to get all of the data off. I might continue to use it that way since it hasn’t failed since removing the housing.
I’ve seen this issue with LaCie cases as well. They get extremely hot and are prone to failure, especially if the case does not have a fan and the drive is used continuously for long periods of time, such for backups.
If you need to use a firewire drive for backup, I would invest in a good case with a fan if possible.
The title says it all. If you find that it does work, please let me know. I’ve tried it and it does not work even though there is a reference to a computer type record in the man page.
Apple’s document on Extending and Troubleshooting Directory Services has a lot of good info.
One correction though is that the debug level must be an integer.
sudo defaults write /Library/Preferences/DirectoryService/DirectoryServiceDebug "Debug Logging Priority Level" -integer 2
I’ve notified Apple, so this may be fixed by the time you read this.
Update: That link is dead. Here is an article that offers some similar information.
I often need to schedule scripts to run at an interval, but I don’t know how long that script will take to complete and I don’t want the script to run again at its normal interval unless the script isn’t running.
I’ve done this with pid files and grepping through ps lists to exit the script if another instance is running, but I was wondering if there is something built into launchd to handle this.
It turns out that launchd does this by default. Just set up your job as normal using StartInterval and if your job hasn’t finished running by the next time it is scheduled to run, launchd will wait until the job finishes. If more than one schedule has passed, the missed jobs will be coalesced into one instance and run just once until the next scheduled run, much like it behaves if the machine goes to sleep.
Another win for launchd.
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.
Mac OS X Server’s AFP server access logs aren’t the greatest (no full paths is a glaring omission), but if you have them enabled, they can be useful for finding who deleted a file or folder for example.
If the item’s name starts with “Important File”, this command gives us the ip address of the client that deleted the item :
file_server:~ root# grep -i "Delete Important File*" /Library/Logs/AppleFileService/AppleFileServiceAccess.log
IP 10.1.21.6 - - [08/Jul/2008:14:26:14 -0500] "Delete Important File 2009.xls" 0 0 0
Then we pass the ip address into this command to give us the login of the user:
file_server:~ root# grep 10.1.21.6 /Library/Logs/AppleFileService/AppleFileServiceAccess.log | grep Login
IP 10.1.21.6 - - [08/Jul/2008:09:05:43 -0500] "Login mpickens" 0 0 0
Finally we can use dscl to lookup the full name the user:
file_server:~ root# dscl localhost read /Search/Users/mpickens RealName
RealName: Pickens, Mary Ellen
Older logs are available too in zipped form. Use gunzip -c to read the contents.
file_server:~ root# gunzip -c '/Library/Logs/AppleFileService/AppleFileServiceAccess.log 12.11.07.gz' | grep Login | grep mpickens
IP 10.1.21.143 - - [14/Dec/2007:19:12:38 -0500] "Login mpickens" 0 0 0
IP 10.1.21.143 - - [14/Dec/2007:19:24:32 -0500] "Login mpickens" 0 0 0
IP 10.1.21.143 - - [17/Dec/2007:09:21:38 -0500] "Login mpickens" 0 0 0
IP 10.1.21.143 - - [17/Dec/2007:10:37:49 -0500] "Login mpickens" 0 0 0
...
While booted from NetRestore I couldn’t figure out what was launching Terminal.app. Finally found the script that was launching it using an option the ps to show the parent process.
Simple, but useful.
ps auxww -o ppid
It was rc.install.
Pattern Buffer: 