Search Results

Search found 8 results on 1 pages for 'morgant'.

Page 1/1 | 1 

• Why is this mod_rewrite RewriteRule directive not working in the .htaccess file?

  - by morgant

  I've got a site that was hosted on a linux el cheapo hosting service that I'm migrating to my Mac OS X 10.5 Leopard Server server running Apache 2.2.8 & PHP 5.2.5 w/rewrite_module enabled and AllowOverride All, but I'm running into an issue with the following lines in the .htaccess file: RewriteEngine On #RewriteRule ^view/([^/\.]+)/?$ /view.php?item=$1 [L] #RewriteRule ^order/([^/\.]+)/?$ /order.php?item=$1 [L] RewriteRule ^category/([^/\.]+)/?$ /category.php?category=$1 [L] As you can see, I've commented out the RewriteRule directives for /view/ and /order/, so I'm only dealing with /category/. When I attempt to load http://domain.tld/category/2/ it runs category.php (I've added debug code to confirm), but $_SERVER['REQUEST_URI'] comes through as /category/2/ and $_GET['category'] comes through as empty. I'm usually fine with troubleshooting .htaccess files and mod_rewrite directives, but this one's got me stumped for some reason. Update: I followed Josh's suggestion and here's the what's dumped to mod_rewrite.log when I try to access http://domain.tld/category/2/: 65.19.81.253 - - [22/Oct/2009:17:31:53 --0400] [domain.tld/sid#100aae0b0][rid#100b5ea98/initial] (2) init rewrite engine with requested uri /category/13 65.19.81.253 - - [22/Oct/2009:17:31:53 --0400] [domain.tld/sid#100aae0b0][rid#100b5ea98/initial] (3) applying pattern '.*' to uri '/category/13' 65.19.81.253 - - [22/Oct/2009:17:31:53 --0400] [domain.tld/sid#100aae0b0][rid#100b5ea98/initial] (1) pass through /category/13 65.19.81.253 - - [22/Oct/2009:17:31:53 --0400] [domain.tld/sid#100aae0b0][rid#100b6aa98/subreq] (3) [perdir /Library/WebServer/Documents/tld.domain.www/] add path info postfix: /Library/WebServer/Documents/tld.domain.www/category.php -> /Library/WebServer/Documents/tld.domain.www/category.php/13 65.19.81.253 - - [22/Oct/2009:17:31:53 --0400] [domain.tld/sid#100aae0b0][rid#100b6aa98/subreq] (3) [perdir /Library/WebServer/Documents/tld.domain.www/] strip per-dir prefix: /Library/WebServer/Documents/tld.domain.www/category.php/13 -> category.php/13 65.19.81.253 - - [22/Oct/2009:17:31:53 --0400] [domain.tld/sid#100aae0b0][rid#100b6aa98/subreq] (3) [perdir /Library/WebServer/Documents/tld.domain.www/] applying pattern '^category/([^/\.]+)/?$' to uri 'category.php/13' 65.19.81.253 - - [22/Oct/2009:17:31:53 --0400] [domain.tld/sid#100aae0b0][rid#100b6aa98/subreq] (1) [perdir /Library/WebServer/Documents/tld.domain.www/] pass through /Library/WebServer/Documents/tld.domain.www/category.php 65.19.81.253 - - [22/Oct/2009:17:31:53 --0400] [domain.tld/sid#100aae0b0][rid#100b5ea98/initial] (3) [perdir /Library/WebServer/Documents/tld.domain.www/] add path info postfix: /Library/WebServer/Documents/tld.domain.www/category.php -> /Library/WebServer/Documents/tld.domain.www/category.php/13 65.19.81.253 - - [22/Oct/2009:17:31:53 --0400] [domain.tld/sid#100aae0b0][rid#100b5ea98/initial] (3) [perdir /Library/WebServer/Documents/tld.domain.www/] strip per-dir prefix: /Library/WebServer/Documents/tld.domain.www/category.php/13 -> category.php/13 65.19.81.253 - - [22/Oct/2009:17:31:53 --0400] [domain.tld/sid#100aae0b0][rid#100b5ea98/initial] (3) [perdir /Library/WebServer/Documents/tld.domain.www/] applying pattern '^category/([^/\.]+)/?$' to uri 'category.php/13' 65.19.81.253 - - [22/Oct/2009:17:31:53 --0400] [domain.tld/sid#100aae0b0][rid#100b5ea98/initial] (1) [perdir /Library/WebServer/Documents/tld.domain.www/] pass through /Library/WebServer/Documents/tld.domain.www/category.php 65.19.81.253 - - [22/Oct/2009:17:31:53 --0400] [domain.tld/sid#100aae0b0][rid#100b6ea98/subreq] (2) init rewrite engine with requested uri /13 65.19.81.253 - - [22/Oct/2009:17:31:53 --0400] [domain.tld/sid#100aae0b0][rid#100b6ea98/subreq] (3) applying pattern '.*' to uri '/13' 65.19.81.253 - - [22/Oct/2009:17:31:53 --0400] [domain.tld/sid#100aae0b0][rid#100b6ea98/subreq] (1) pass through /13 65.19.81.253 - - [22/Oct/2009:17:31:53 --0400] [domain.tld/sid#100aae0b0][rid#100b6ea98/subreq] (3) [perdir /Library/WebServer/Documents/tld.domain.www/] strip per-dir prefix: /Library/WebServer/Documents/tld.domain.www/13 -> 13 65.19.81.253 - - [22/Oct/2009:17:31:53 --0400] [domain.tld/sid#100aae0b0][rid#100b6ea98/subreq] (3) [perdir /Library/WebServer/Documents/tld.domain.www/] applying pattern '^category/([^/\.]+)/?$' to uri '13' 65.19.81.253 - - [22/Oct/2009:17:31:53 --0400] [domain.tld/sid#100aae0b0][rid#100b6ea98/subreq] (1) [perdir /Library/WebServer/Documents/tld.domain.www/] pass through /Library/WebServer/Documents/tld.domain.www/13

  Read the article

• Why is this mod_rewrite RewriteRule directive not working in the .htaccess file?

  - by morgant

  I've got a site that was hosted on a linux el cheapo hosting service that I'm migrating to my Mac OS X 10.5 Leopard Server server running Apache 2.2.8 & PHP 5.2.5 w/rewrite_module enabled and AllowOverride All, but I'm running into an issue with the following lines in the .htaccess file: RewriteEngine On #RewriteRule ^view/([^/\.]+)/?$ /view.php?item=$1 [L] #RewriteRule ^order/([^/\.]+)/?$ /order.php?item=$1 [L] RewriteRule ^category/([^/\.]+)/?$ /category.php?category=$1 [L] As you can see, I've commented out the RewriteRule directives for /view/ and /order/, so I'm only dealing with /category/. When I attempt to load http://domain.tld/category/2/ it runs category.php (I've added debug code to confirm), but $_SERVER['REQUEST_URI'] comes through as /category/2/ and $_GET['category'] comes through as empty. I'm usually fine with troubleshooting .htaccess files and mod_rewrite directives, but this one's got me stumped for some reason. Update: I followed Josh's suggestion and here's the what's dumped to mod_rewrite.log when I try to access http://domain.tld/category/2/: 65.19.81.253 - - [22/Oct/2009:17:31:53 --0400] [domain.tld/sid#100aae0b0][rid#100b5ea98/initial] (2) init rewrite engine with requested uri /category/13 65.19.81.253 - - [22/Oct/2009:17:31:53 --0400] [domain.tld/sid#100aae0b0][rid#100b5ea98/initial] (3) applying pattern '.*' to uri '/category/13' 65.19.81.253 - - [22/Oct/2009:17:31:53 --0400] [domain.tld/sid#100aae0b0][rid#100b5ea98/initial] (1) pass through /category/13 65.19.81.253 - - [22/Oct/2009:17:31:53 --0400] [domain.tld/sid#100aae0b0][rid#100b6aa98/subreq] (3) [perdir /Library/WebServer/Documents/tld.domain.www/] add path info postfix: /Library/WebServer/Documents/tld.domain.www/category.php -> /Library/WebServer/Documents/tld.domain.www/category.php/13 65.19.81.253 - - [22/Oct/2009:17:31:53 --0400] [domain.tld/sid#100aae0b0][rid#100b6aa98/subreq] (3) [perdir /Library/WebServer/Documents/tld.domain.www/] strip per-dir prefix: /Library/WebServer/Documents/tld.domain.www/category.php/13 -> category.php/13 65.19.81.253 - - [22/Oct/2009:17:31:53 --0400] [domain.tld/sid#100aae0b0][rid#100b6aa98/subreq] (3) [perdir /Library/WebServer/Documents/tld.domain.www/] applying pattern '^category/([^/\.]+)/?$' to uri 'category.php/13' 65.19.81.253 - - [22/Oct/2009:17:31:53 --0400] [domain.tld/sid#100aae0b0][rid#100b6aa98/subreq] (1) [perdir /Library/WebServer/Documents/tld.domain.www/] pass through /Library/WebServer/Documents/tld.domain.www/category.php 65.19.81.253 - - [22/Oct/2009:17:31:53 --0400] [domain.tld/sid#100aae0b0][rid#100b5ea98/initial] (3) [perdir /Library/WebServer/Documents/tld.domain.www/] add path info postfix: /Library/WebServer/Documents/tld.domain.www/category.php -> /Library/WebServer/Documents/tld.domain.www/category.php/13 65.19.81.253 - - [22/Oct/2009:17:31:53 --0400] [domain.tld/sid#100aae0b0][rid#100b5ea98/initial] (3) [perdir /Library/WebServer/Documents/tld.domain.www/] strip per-dir prefix: /Library/WebServer/Documents/tld.domain.www/category.php/13 -> category.php/13 65.19.81.253 - - [22/Oct/2009:17:31:53 --0400] [domain.tld/sid#100aae0b0][rid#100b5ea98/initial] (3) [perdir /Library/WebServer/Documents/tld.domain.www/] applying pattern '^category/([^/\.]+)/?$' to uri 'category.php/13' 65.19.81.253 - - [22/Oct/2009:17:31:53 --0400] [domain.tld/sid#100aae0b0][rid#100b5ea98/initial] (1) [perdir /Library/WebServer/Documents/tld.domain.www/] pass through /Library/WebServer/Documents/tld.domain.www/category.php 65.19.81.253 - - [22/Oct/2009:17:31:53 --0400] [domain.tld/sid#100aae0b0][rid#100b6ea98/subreq] (2) init rewrite engine with requested uri /13 65.19.81.253 - - [22/Oct/2009:17:31:53 --0400] [domain.tld/sid#100aae0b0][rid#100b6ea98/subreq] (3) applying pattern '.*' to uri '/13' 65.19.81.253 - - [22/Oct/2009:17:31:53 --0400] [domain.tld/sid#100aae0b0][rid#100b6ea98/subreq] (1) pass through /13 65.19.81.253 - - [22/Oct/2009:17:31:53 --0400] [domain.tld/sid#100aae0b0][rid#100b6ea98/subreq] (3) [perdir /Library/WebServer/Documents/tld.domain.www/] strip per-dir prefix: /Library/WebServer/Documents/tld.domain.www/13 -> 13 65.19.81.253 - - [22/Oct/2009:17:31:53 --0400] [domain.tld/sid#100aae0b0][rid#100b6ea98/subreq] (3) [perdir /Library/WebServer/Documents/tld.domain.www/] applying pattern '^category/([^/\.]+)/?$' to uri '13' 65.19.81.253 - - [22/Oct/2009:17:31:53 --0400] [domain.tld/sid#100aae0b0][rid#100b6ea98/subreq] (1) [perdir /Library/WebServer/Documents/tld.domain.www/] pass through /Library/WebServer/Documents/tld.domain.www/13

  Read the article

• Why can't I use SSL certs imported via Server Admin in a custom Apache install?

  - by morgant

  I've got a couple of Mac OS X 10.6.8 Server web servers that run a custom AMP255 (Apache 2.x, MySQL 5.x, and PHP 5.x) stack installed using MacPorts. We've got a lot of Mac OS X Server servers and generally install SSL certs via Server Admin and they "just work" in the built-in services, however, these web servers have always had SSL certs installed in a non-standard location and used only for Apache. Long story short, we're trying to standardize this part of our administration and install certs via Server Admin, but have run into the following issue: when the certs are installed via Server Admin and referenced in our Apache conf files, Apache then prompts for a password upon trying to start. It does not seem to be any password we know, certainly not the admin or keychain passwords! We've added the _www user to the certusers (mainly just to ensure they have the proper access to the private key in /etc/certificates/). So, with the custom installed certs we have the following files (basically just pasted in from the company we purchase our certs from): -rw-r--r-- 1 root admin 1395 Apr 10 11:22 *.domain.tld.ca -rw-r--r-- 1 root admin 1656 Apr 10 11:21 *.domain.tld.cert -rw-r--r-- 1 root admin 1680 Apr 10 11:22 *.domain.tld.key And the following in the VirtualHost in /opt/local/apache2/conf/extra/httpd-ssl.conf: SSLCertificateFile /path/to/certs/*.domain.tld.cert SSLCertificateKeyFile /path/to/certs/*.domain.tld.key SSLCACertificateFile /path/to/certs/*.domain.tld.ca This setup functions normally. If we use the certs installed via Server Admin, which both Server Admin & Keychain Assistant show as valid, they're installed in /etc/certificates/ as follows: -rw-r--r-- 1 root wheel 1655 Apr 9 13:44 *.domain.tld.SOMELONGHASH.cert.pem -rw-r--r-- 1 root wheel 4266 Apr 9 13:44 *.domain.tld.SOMELONGHASH.chain.pem -rw-r----- 1 root certusers 3406 Apr 9 13:44 *.domain.tld.SOMELONGHASH.concat.pem -rw-r----- 1 root certusers 1751 Apr 9 13:44 *.domain.tld.SOMELONGHASH.key.pem And if we replace the aforementioned lines in our httpd-ssl.conf with the following: SSLCertificateFile /etc/certificates/*.domain.tld.SOMELONGHASH.cert.pem SSLCertificateKeyFile /etc/certificates/*.domain.tld.SOMELONGHASH.key.pem SSLCertificateChainFile /etc/certificates/*.domain.tld.SOMELONGHASH.chain.pem This prompts for the unknown password. I have also tried httpd-ssl.conf configured as follows: SSLCertificateFile /etc/certificates/*.domain.tld.SOMELONGHASH.cert.pem SSLCertificateKeyFile /etc/certificates/*.domain.tld.SOMELONGHASH.key.pem SSLCertificateChainFile /etc/certificates/*.domain.tld.SOMELONGHASH.concat.pem And as: SSLCertificateFile /etc/certificates/*.domain.tld.SOMELONGHASH.cert.pem SSLCertificateKeyFile /etc/certificates/*.domain.tld.SOMELONGHASH.key.pem SSLCACertificateFile /etc/certificates/*.domain.tld.SOMELONGHASH.chain.pem We've verified that the certificate is configured to allow all applications access it (in Keychain Assistant). A diff of the /etc/certificates/*.domain.tld.SOMELONGHASH.key.pem & *.domain.tld.key files shows the former is encrypted and the latter is not, so we're assuming that Server Admin/Keychain Assistant is encrypting them for some reason. I know I can create an unencrypted key file as follows: sudo openssl rsa -in /etc/certificates/*.domain.tld.SOMELONGHASH.key.pem -out /etc/certificates/*.domain.tld.SOMELONGHASH.key.no_password.pem But, I can't do that without entering the password. I thought maybe I could export an unencrypted copy of the key from Keychain Admin, but I'm not seeing such an option (not to mention that the .pem options are greyed out in all export options). Any assistance would be greatly appreciated.

  Read the article

• How can I resolve this one application coming up with an "You don't have permission to use the application" error?

  - by morgant

  I've got a Mac OS X 10.6 Snow Leopard Server Open Directory Master with a user who's getting Mobility & Application managed preferences from a group (the only group they're a member of). The workstation is also running Mac OS X 10.6 Snow Leopard, when the user logs in and tries to run our primary application which they're explicitly allowed to run (via the group's preferences), it says "You don't have permission to use the application 'Blah'". Now, the application is added to the group's list of always allowed applications, unsigned (so a minor difference in application version or file contents shouldn't disallow it). It even lives in a subdirectory of /Applications which is in the list of folders to allow applications. I've run into this when logging this user into new workstations and the following usually works: Log them out Remove the following files from their mobile home folder on the workstation: /Library/Managed\ Preferences/, ~/.FileSync, ~/Library/Preferences/com.apple.finder.plist, and ~/Library/Preferences/com.apple.MCX.plist. Remove the following files from their network home folder on the server: ~/.FileSync, ~/Library/Preferences/com.apple.finder.plist, and ~/Library/Preferences/com.apple.MCX.plist. Log them back in on the workstation. However, this no longer resolves the issue. Their Home Sync preferences are set (on the group) to sync ~, but not the following files (manually, at login, and at logout... no background sync here): ~/.SymAVQSFile ~/NAVMac800QSFile ~/Library ~/.FileSync ~/.account Their Preferences Sync preferences are set (also on the group) to sync ~/Library & ~/Documents/Microsoft User Data, but not the following files (also manually, at login, and at logout... no background sync): ~/.SymAVQSFile ~/.Trash ~/.Trashes ~/Documents/Microsoft User Data/Entourage Temp ~/Library/Application Support/SyncServices ~/Library/Application Support/MobileSync ~/Library/Caches ~/Library/Calendars/Calendar Cache ~/Library/Logs ~/Library/Mail/AvailableFeeds ~/Library/Mail/Envelope Index ~/Library/Preferences/Macromedia/ ~/Library/Printers ~/Library/PubSub/Database ~/Library/PubSub/Downloads ~/Library/PubSub/Feeds ~/Library/Safari/Icons.db ~/Library/Safari/HistoryIndex.sk ~/Library/iTunes/iPhone Software Updates IMAP-* Exchange-* EWS-* Mac-* ~/Library/Preferences/ByHost ~/Library/Preferences/com.apple.dock.plist ~/Library/Preferences/com.apple.sitebarlists.plist ~/Library/Application Support/4D ~/Library/Preferences/com.apple.MCX.plist ~/.FileSync ~/.account Even with ~/Library/Preferences/com.apple.MCX.plist prevented from syncing during a Preferences Sync, it still seems to show up in the network home on the server frequently. Are there any other files other than ~/Library/Preferences/com.apple.MCX.plist that contain application Managed Preferences that might be causing this one app to be showing up as not allowed? Any ideas on how ~/Library/Preferences/com.apple.MCX.plist keeps getting sync'd back up the network home folder on the server? Update: I thought I had found a workaround this morning, but it also seemed to be extremely temporary. Basically, loking at /Library/Managed\ Preferences/[shortname]/com.apple.applicationaccess.new.plist I discovered that it didn't have an entry for the application in question, but /Library/Managed\ Preferences/[shortname]/complete.plist did. Naturally, I deleted com.apple.applicationaccess.new.plist, logged in again, and it worked... on one workstation. It failed on others, and after logging out & back in a couple more times it started failing on all of them again, even after further deletions of com.apple.applicationaccess.new.plist. Oddly, com.apple.applicationaccess.new.plist & complete.plist do both contain an entry for the application in question now, but it still says it's not allowed. Further Update: Okay, so I now have a reproducible workaround which seems to be required after every reboot of the workstation: Log in as the user (you'll discover you cannot launch the application in question). Fast User Switch to the local admin account on the workstation (we always have one on every machine). From that local admin account, run sudo mcxrefresh -n 'shortname' (logging out and back in as the user in question will not work). Fast User Switch back to the user (you'll still not be allowed to run the application). Log the user out and back in (you'll now be able to run the application in question.) Fast User Switch back to the local admin account, log it out, and log back in as the user in question. If you do all that exactly as described it'll keep working through log out & log back in, but NOT through a reboot. If, after a reboot, you try something like logging in as the local admin account, running sudo mcxrefresh -n 'shortname', logging out, then logging in as the user in question, it will NOT work. Yet Another Update We don't have any computer groups in our Open Directory, so it shouldn't be getting any conflicting settings from there. I ran sudo mcxquery -format xml -user shortname -group groupname before & after performing the aforementioned process to allow the application in question to be run and the results were identical (saved the result to files & diff'd... I'm not just guessing here). One Step Forward, Half a Step Back: When the Mac OS X 10.6.5 Server update was released, we upgraded our Open Directory Master to it as the changes included the following managed preferences fixes which I hoped might address this issue: Addresses an issue that could prevent managed preferences from being applied when a user logs in on a workstation that has been idle. Fixes an issue that could prevent administrators from bypassing client management settings on a workstation. This seemed to improve the situation slightly. The application in question now usually launches without error. If, and when it does launch with the "You don't have permission to use the application" error, logging the user out and back in seems to correct it. That said, we've since had to add a couple of applications to the user's ~/Applications/ directory and those are still prevented from launching. The workstations are running Mac OS X 10.6.4, the OD Master (which the workstations are bound to) is running Mac OS 10.6.5 Server (although there are two OD Replicas still running 10.6.4 Server), and we're using Workgroup Manager 10.6.3 (which is included with the Server Admin Tools 10.6.5 upgrade) to add the applications (unsigned, as always). This time, I've caught the following in /var/log/system.log when attempting to launch one of the allowed applications from ~/Applications: Dec 22 17:36:24 hostname parentalcontrolsd[43221]: -[ActivityTracker checkApp:csFlags:] [954:username] -- *** Incoming app appears to be masquerading as white listed app and failed signature validation: /Users/username/Applications/FileMaker Pro 5.5/FileMaker Pro.app/Contents/MacOS/FileMaker Pro. Note: This may be a valid app of a different version than what was whitelisted (on a different volume?) Dec 22 17:36:24 hostname [0x0-0xa42a42].com.filemaker.filemakerpro[43304]: launch of /Users/username/Applications/FileMaker Pro 5.5/FileMaker Pro.app/Contents/MacOS/FileMaker Pro was blocked Dec 22 17:36:24 hostname com.apple.launchd.peruser.1340[6375] ([0x0-0xa42a42].com.filemaker.filemakerpro[43304]): Exited with exit code: 255 Dec 22 17:36:24 hostname parentalcontrolsd[43221]: -[ActivityTracker(Private) _removeAppFromWhiteList:] [1362:username] -- *** Couldn't find local user record Running sudo mcxquery -format xml -user username -group groupname includes the following entry for FileMaker Pro 5.5 (and appears to include a full integration of the user's application whitelist & group's application whitelist): <dict> <key>bundleID</key> <string>com.filemaker.filemakerpro</string> <key>displayName</key> <string>FileMaker Pro</string> </dict> Note the lack of <key>appID</key><data> ... </data> which seems to specify a signed application. While whitelisted directories also appear to be correctly listed in the results, they too do not actually allow the applications to be run either. What is going on here?! Where else should I be looking?

  Read the article

• How to resolve "HTTP/1.1 403 Forbidden" errors from iCal/CalDAV server after upgrade to Snow Leopard Server?

  - by morgant

  We recently upgraded our Open Directory Master & Replica to Mac OS X 10.6.4 Snow Leopard Server. We had a mismatched server FQDN & LDAP Search Base/Kerberos Realm, so we exported all users & groups, created the new Open Directory Master w/matching FQDN & Search Base/Realm, reimported users & groups, and re-bound all servers & workstations to the new OD Master. At the same time as all of this, we upgraded our iCal/CalDAV server to Mac OS X 10.6.4 Snow Leopard Server. Ever since doing so, we've seen the following issues with our iCal/CalDAV server and iCal clients on both Mac OS X 10.5 Leopard & Mac OS X 10.6: If a user attempts to move or delete an event (single or repeating) that was created prior to the upgrade to 10.6 Server, they get the following error: Access to "blah" in "blah" in account "blah" is not permitted. The server responded: "HTTP/1.1 403 Forbidden" to operation CalDAVWriteEntityQueueableOperation. New users added to the directory get the following error when attempting to add their account to in iCal's preferences: The user "blah" has no configured pricipals. Confirm with your network administrator that your account has at least one CalDAV principal configured. Interestingly, we've since discovered that users seem to be able to delete individual events from an old repeating event without error, but that's a massive amount of work to get rid of a repeating event. I will note that we have not yet added an SRV record in DNS as instructed on page 19 of iCal_Server_Admin_v10.6.pdf. Further Investigation: In this particular case, a user is attempting to decline repeating events created prior to the upgrade to Snow Leopard Server. Granting the user full write access with sudo calendarserver_manage_principals --add-write-proxy users:user1 users:user2 (which did work) doesn't allow deletion of the events. Still get the usual error: Access to "blah blah" in "blah blah" in account "blah blah" is not permitted. The server responded: "HTTP/1.1 403 Forbidden" to operation CalDAVWriteEntityQueueableOperation. The error that shows up in /var/log/caldavd/error.log on the iCal Server when attempting to delete one of the events is: 2011-03-17 15:14:30-0400 [-] [caldav-8009] [PooledMemCacheProtocol,client] [twistedcaldav.extensions#info] PUT /calendars/__uids__/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/calendar/XXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX.ics HTTP/1.1 2011-03-17 15:14:30-0400 [-] [caldav-8009] [PooledMemCacheProtocol,client] [twistedcaldav.scheduling.implicit#error] Cannot change ORGANIZER: UID:XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX And the error in /var/log/system.log on the client is: Mar 17 15:14:30 192-168-21-169-dhcp iCal[33509]: CalDAV CalDAVWriteEntityQueueableOperation failed: status 'HTTP/1.1 403 Forbidden' request:\n\nBEGIN:VCALENDAR^M\nVERSION:2.0^M\nPRODID:-//Apple Inc.//iCal 3.0//EN^M\nCALSCALE:GREGORIAN^M\nBEGIN:VTIMEZONE^M\nTZID:US/Eastern^M\nBEGIN:DAYLIGHT^M\nTZOFFSETFROM:-0500^M\nTZOFFSETTO:-0400^M\nDTSTART:20070311T020000^M\nRRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU^M\nTZNAME:EDT^M\nEND:DAYLIGHT^M\nBEGIN:STANDARD^M\nTZOFFSETFROM:-0400^M\nTZOFFSETTO:-0500^M\nDTSTART:20071104T020000^M\nRRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU^M\nTZNAME:EST^M\nEND:STANDARD^M\nEND:VTIMEZONE^M\nBEGIN:VEVENT^M\nSEQUENCE:5^M\nDTSTART;TZID=US/Eastern:20090117T094500^M\nDTSTAMP:20081227T143043Z^M\nSUMMARY:blah blah^M\nATTENDEE;CN="First Last";CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT:urn:uuid^M\n :XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX^M\nATTENDEE;CN="First Last";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:mailto:user@d^M\n omain.tld^M\nEXDATE;TZID=US/Eastern:20110319T094500^M\nDTEND;TZID=US/Eastern:20090117T183000^M\nRRULE:FREQ=WEEKLY;INTERVAL=1^M\nTRANSP:OPAQUE^M\nUID:XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX^M\nORGANIZER;CN="First Last":mailto:[email protected]^M\nX-WR-ITIPSTATUSML:UNCLEAN^M\nCREATED:20110317T191348Z^M\nEND:VEVENT^M\nEND:VCALENDAR^M\n\n\n... response:\nHTTP/1.1 403 Forbidden^M\nDate: Thu, 17 Mar 2011 19:14:30 GMT^M\nDav: 1, access-control, calendar-access, calendar-schedule, calendar-auto-schedule, calendar-availability, inbox-availability, calendar-proxy, calendarserver-private-events, calendarserver-private-comments, calendarserver-principal-property-search^M\nContent-Type: text/xml^M\nContent-Length: 134^M\nServer: Twisted/8.2.0 TwistedWeb/8.2.0 TwistedCalDAV/2.5 (iCal Server v12.56.21)^M\n^M\n<?xml version='1.0' encoding='UTF-8'?><error xmlns='DAV:'>^M\n <valid-attendee-change xmlns='urn:ietf:params:xml:ns:caldav'/>^M\n</error> One thing I have noticed, and I'm not sure if this has any real effect is that in many of these pre-Snow Leopard Server migration events, the ORGANIZER is specified like the following: ORGANIZER;CN=First Last:mailto:[email protected] But newer ones are more like one of the two following: ORGANIZER;CN=First Last;[email protected];SCHEDULE-STATUS=1 ORGANIZER;CN=First Last;[email protected]:urn:uuid:XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX iCal_Server_Admin_v10.6.pdf notes that the ".db.sqlite" files are completely disposable, they're merely a performance cache and are re-built on the fly, so are safe to delete. I did delete the one for the organizer's calendars and it took longer to process the attempted event delete while it rebuilt the database, but still errored out in the end. FWIW the error is thrown by this code: https://trac.calendarserver.org/browser/CalendarServer/trunk/twistedcaldav/scheduling/implicit.py Any further suggestions? I see lots of questions about this in my Google searches, but not solutions and this is a widespread problem on our iCal Server. Now, we mostly try to get users to ignore them (hence the amount of time this question has been open), but every now and then I dig in deeper trying to find the culprit and/or solution.

  Read the article

• How can I resolve this one application coming up with an "You don't have permission to use the application" error?

  - by morgant

  I've got a Mac OS X 10.6 Snow Leopard Server Open Directory Master with a user who's getting Mobility & Application managed preferences from a group (the only group they're a member of). The workstation is also running Mac OS X 10.6 Snow Leopard, when the user logs in and tries to run our primary application which they're explicitly allowed to run (via the group's preferences), it says "You don't have permission to use the application 'Blah'". Now, the application is added to the group's list of always allowed applications, unsigned (so a minor difference in application version or file contents shouldn't disallow it). It even lives in a subdirectory of /Applications which is in the list of folders to allow applications. I've run into this when logging this user into new workstations and the following usually works: Log them out Remove the following files from their mobile home folder on the workstation: /Library/Managed\ Preferences/, ~/.FileSync, ~/Library/Preferences/com.apple.finder.plist, and ~/Library/Preferences/com.apple.MCX.plist. Remove the following files from their network home folder on the server: ~/.FileSync, ~/Library/Preferences/com.apple.finder.plist, and ~/Library/Preferences/com.apple.MCX.plist. Log them back in on the workstation. However, this no longer resolves the issue. Their Home Sync preferences are set (on the group) to sync ~, but not the following files (manually, at login, and at logout... no background sync here): ~/.SymAVQSFile ~/NAVMac800QSFile ~/Library ~/.FileSync ~/.account Their Preferences Sync preferences are set (also on the group) to sync ~/Library & ~/Documents/Microsoft User Data, but not the following files (also manually, at login, and at logout... no background sync): ~/.SymAVQSFile ~/.Trash ~/.Trashes ~/Documents/Microsoft User Data/Entourage Temp ~/Library/Application Support/SyncServices ~/Library/Application Support/MobileSync ~/Library/Caches ~/Library/Calendars/Calendar Cache ~/Library/Logs ~/Library/Mail/AvailableFeeds ~/Library/Mail/Envelope Index ~/Library/Preferences/Macromedia/ ~/Library/Printers ~/Library/PubSub/Database ~/Library/PubSub/Downloads ~/Library/PubSub/Feeds ~/Library/Safari/Icons.db ~/Library/Safari/HistoryIndex.sk ~/Library/iTunes/iPhone Software Updates IMAP-* Exchange-* EWS-* Mac-* ~/Library/Preferences/ByHost ~/Library/Preferences/com.apple.dock.plist ~/Library/Preferences/com.apple.sitebarlists.plist ~/Library/Application Support/4D ~/Library/Preferences/com.apple.MCX.plist ~/.FileSync ~/.account Even with ~/Library/Preferences/com.apple.MCX.plist prevented from syncing during a Preferences Sync, it still seems to show up in the network home on the server frequently. Are there any other files other than ~/Library/Preferences/com.apple.MCX.plist that contain application Managed Preferences that might be causing this one app to be showing up as not allowed? Any ideas on how ~/Library/Preferences/com.apple.MCX.plist keeps getting sync'd back up the network home folder on the server? Update: I thought I had found a workaround this morning, but it also seemed to be extremely temporary. Basically, loking at /Library/Managed\ Preferences/[shortname]/com.apple.applicationaccess.new.plist I discovered that it didn't have an entry for the application in question, but /Library/Managed\ Preferences/[shortname]/complete.plist did. Naturally, I deleted com.apple.applicationaccess.new.plist, logged in again, and it worked... on one workstation. It failed on others, and after logging out & back in a couple more times it started failing on all of them again, even after further deletions of com.apple.applicationaccess.new.plist. Oddly, com.apple.applicationaccess.new.plist & complete.plist do both contain an entry for the application in question now, but it still says it's not allowed. Further Update: Okay, so I now have a reproducible workaround which seems to be required after every reboot of the workstation: Log in as the user (you'll discover you cannot launch the application in question). Fast User Switch to the local admin account on the workstation (we always have one on every machine). From that local admin account, run sudo mcxrefresh -n 'shortname' (logging out and back in as the user in question will not work). Fast User Switch back to the user (you'll still not be allowed to run the application). Log the user out and back in (you'll now be able to run the application in question.) Fast User Switch back to the local admin account, log it out, and log back in as the user in question. If you do all that exactly as described it'll keep working through log out & log back in, but NOT through a reboot. If, after a reboot, you try something like logging in as the local admin account, running sudo mcxrefresh -n 'shortname', logging out, then logging in as the user in question, it will NOT work. Yet Another Update We don't have any computer groups in our Open Directory, so it shouldn't be getting any conflicting settings from there. I ran sudo mcxquery -format xml -user shortname -group groupname before & after performing the aforementioned process to allow the application in question to be run and the results were identical (saved the result to files & diff'd... I'm not just guessing here). One Step Forward, Half a Step Back: When the Mac OS X 10.6.5 Server update was released, we upgraded our Open Directory Master to it as the changes included the following managed preferences fixes which I hoped might address this issue: Addresses an issue that could prevent managed preferences from being applied when a user logs in on a workstation that has been idle. Fixes an issue that could prevent administrators from bypassing client management settings on a workstation. This seemed to improve the situation slightly. The application in question now usually launches without error. If, and when it does launch with the "You don't have permission to use the application" error, logging the user out and back in seems to correct it. That said, we've since had to add a couple of applications to the user's ~/Applications/ directory and those are still prevented from launching. The workstations are running Mac OS X 10.6.4, the OD Master (which the workstations are bound to) is running Mac OS 10.6.5 Server (although there are two OD Replicas still running 10.6.4 Server), and we're using Workgroup Manager 10.6.3 (which is included with the Server Admin Tools 10.6.5 upgrade) to add the applications (unsigned, as always). This time, I've caught the following in /var/log/system.log when attempting to launch one of the allowed applications from ~/Applications: Dec 22 17:36:24 hostname parentalcontrolsd[43221]: -[ActivityTracker checkApp:csFlags:] [954:username] -- *** Incoming app appears to be masquerading as white listed app and failed signature validation: /Users/username/Applications/FileMaker Pro 5.5/FileMaker Pro.app/Contents/MacOS/FileMaker Pro. Note: This may be a valid app of a different version than what was whitelisted (on a different volume?) Dec 22 17:36:24 hostname [0x0-0xa42a42].com.filemaker.filemakerpro[43304]: launch of /Users/username/Applications/FileMaker Pro 5.5/FileMaker Pro.app/Contents/MacOS/FileMaker Pro was blocked Dec 22 17:36:24 hostname com.apple.launchd.peruser.1340[6375] ([0x0-0xa42a42].com.filemaker.filemakerpro[43304]): Exited with exit code: 255 Dec 22 17:36:24 hostname parentalcontrolsd[43221]: -[ActivityTracker(Private) _removeAppFromWhiteList:] [1362:username] -- *** Couldn't find local user record Running sudo mcxquery -format xml -user username -group groupname includes the following entry for FileMaker Pro 5.5 (and appears to include a full integration of the user's application whitelist & group's application whitelist): <dict> <key>bundleID</key> <string>com.filemaker.filemakerpro</string> <key>displayName</key> <string>FileMaker Pro</string> </dict> Note the lack of <key>appID</key><data> ... </data> which seems to specify a signed application. While whitelisted directories also appear to be correctly listed in the results, they too do not actually allow the applications to be run either. What is going on here?! Where else should I be looking?

  Read the article

• How to resolve `bootpd` crashing constantly on Mac OS X 10.6.4 Snow Leopard Server?

  - by morgant

  I've got a Mac Pro running Mac OS X 10.6.4 Snow Leopard Server and it's recently started getting numerous 'kNetworkError's in Server Admin.app when viewing services. It's acting as a gateway w/NAT and has been so for quite some time. There is one glaring issue, bootpd crashes all the time with the following errors in `/var/log/system.log/: Aug 12 16:54:59 servername bootpd[3572]: server starting Aug 12 16:54:59 servername bootpd[3572]: server name servername.domain.tld Aug 12 16:54:59 servername bootpd[3572]: interface en0: ip 10.0.1.9 mask 255.255.255.0 Aug 12 16:54:59 servername bootpd[3572]: bsdpd: re-reading configuration Aug 12 16:54:59 servername bootpd[3572]: bsdpd: shadow file size will be set to 48 megabytes Aug 12 16:54:59 servername bootpd[3572]: bsdpd: age time 00:15:00 Aug 12 16:54:59 servername bootpd[3572]: [3572] detected buffer overflow Aug 12 16:54:59 servername com.apple.launchd[1] (com.apple.bootpd[3572]): Job appears to have crashed: Abort trap Aug 12 16:54:59 servername com.apple.ReportCrash.Root[3571]: 2010-08-12 16:54:59.828 ReportCrash[3571:2807] Saved crash report for bootpd[3572] version ??? (???) to /Library/Logs/DiagnosticReports/bootpd_2010-08-12-165459_localhost.crash It is correctly configured to serve DHCP through en1 (not en0), the "LAN" port. This happens even with no hardware (even switches) connected to the "LAN" port. There are no DHCP clients listed. Oddly, the "Overview" shows 1 static map, but nothing is listed under "Static Maps" and there are no "Computers" in Open Directory. /var/db/dhcp_leases is empty. /Library/Logs/DiagnosticReports/bootpd_2010-08-12-165459_localhost.crash is as follows: Process: bootpd [3572] Path: /usr/libexec/bootpd Identifier: bootpd Version: ??? (???) Code Type: X86-64 (Native) Parent Process: launchd [1] Date/Time: 2010-08-12 16:54:59.713 -0400 OS Version: Mac OS X Server 10.6.4 (10F569) Report Version: 6 Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Application Specific Information: __abort() called Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 libSystem.B.dylib 0x00007fff803c13d6 __kill + 10 1 libSystem.B.dylib 0x00007fff80461913 __abort + 103 2 libSystem.B.dylib 0x00007fff80456157 mach_msg_receive + 0 3 libSystem.B.dylib 0x00007fff803b92cf __strncpy_chk + 14 4 bootpd 0x0000000100014e5d PLCache_read + 782 5 bootpd 0x0000000100004a3d BSDPClients_init + 68 6 bootpd 0x00000001000053b5 bsdp_init + 2396 7 bootpd 0x000000010000200b S_update_services + 1228 8 bootpd 0x0000000100002344 S_server_loop + 571 9 bootpd 0x0000000100003963 main + 1766 10 bootpd 0x0000000100000984 start + 52 Thread 0 crashed with X86 Thread State (64-bit): rax: 0x0000000000000000 rbx: 0x00007fff5fbfe220 rcx: 0x00007fff5fbfe218 rdx: 0x0000000000000000 rdi: 0x0000000000000df4 rsi: 0x0000000000000006 rbp: 0x00007fff5fbfe240 rsp: 0x00007fff5fbfe218 r8: 0x0000000000000001 r9: 0x0000000100114280 r10: 0x00007fff803bd412 r11: 0xffffff80002e1680 r12: 0xffffffffffffffff r13: 0x00007fff5fbfe330 r14: 0x00007fff5fbfe33b r15: 0x00007fff7009bec0 rip: 0x00007fff803c13d6 rfl: 0x0000000000000202 cr2: 0x000000010004c000 Any thoughts or suggestions as to resolving this?

  Read the article

• How do I increase Relevance value in an advanced MySQL query?

  - by morgant

  I've got a MySQL query similar to the following: SELECT *, MATCH (`Description`) AGAINST ('+ipod +touch ' IN BOOLEAN MODE) * 8 + MATCH(`Description`) AGAINST ('ipod touch' IN BOOLEAN MODE) AS Relevance FROM products WHERE ( MATCH (`Description`) AGAINST ('+ipod +touch' IN BOOLEAN MODE) OR MATCH(`LongDescription`) AGAINST ('+ipod +touch' IN BOOLEAN MODE) ) HAVING Relevance > 1 ORDER BY Relevance DESC Now, I've made the query more advanced by also searching for UPC: SELECT *, MATCH (`Description`) AGAINST ('+ipod +touch ' IN BOOLEAN MODE) * 8 + MATCH(`Description`) AGAINST ('ipod touch' IN BOOLEAN MODE) + `UPC` = '123456789012' * 16 AS Relevance FROM products WHERE ( MATCH (`Description`) AGAINST ('+ipod +touch' IN BOOLEAN MODE) OR MATCH(`LongDescription`) AGAINST ('+ipod +touch' IN BOOLEAN MODE) ) AND `UPC` = '123456789012' HAVING Relevance > 1 ORDER BY Relevance DESC That'll return results, but the fact that I had a successful match on the UPC does not increase the value of Relevance. Can I only do that kind of calculation w/full text searches like MATCH() AGAINST()? Clarification: Okay, so my real question is, why does the following not have a Relevance = 16? SELECT `UPC`, `UPC` = '123456789012' * 16 AS Relevance FROM products WHERE `UPC` = '123456789012' HAVING Relevance > 1 ORDER BY Relevance DESC

  Read the article

1