REDELIJKHEID
The earlier posts on my logging experiences didn't include the logrotation solution I used on my OS X Server.
When you create a new logfile (and have syslog fill that file up), you're gonna run into a lack of space sooner or later. This happens because the syslog server keeps writing data to that file, and the system doesn't 'recognize' (read: isn't configured) the file for logrotation. So, you need to tell the logrotation process to include the new logfile (and what to do with it).
For testing and development purposes I run a Cisco Secure ACS 5.x in a virtual machine at home. In this environment I also run an Apple Directory Service. I'll be using this setup to test several 802.1x and RADIUS authentication schemes.
To get things going I needed to connect to the ACS to my LDAP Directory. The Apple Directory Service is a bit different from the regular LDAP implementations. They seem to add the 'apple' reference in a lot of attribute values. Thankfully the ACS has a very versatile configuration interface.
;)
Apple references in attribute valuesNormally, the group definition would be 'group' instead of 'apple-group'. So the configuration of the ACS should reflect these variations to the standard.
Earlier this week I got the announcement (I opened an Adobe application) that there was an update for the Adobe Reader app. Security-conscious as I am, I fired up the update process.
Each time, this process stopped at the (near??) end of the installation with the following error:
The operation couldn’t be completed. (com.adobe.ARM error 1807.)
The error also suggested looking at the log file. Examination of this file showed nothing out of the ordinary. At least not that made sense to me.
There were some lines in the log that made me try to do a work-around (in bold);
After the challenges with the iCalDAV server in OSX, I gave up on getting the Addressbook server up-and-running. Somehow, the clients couldn't wouldn't connect. No matter what configuration parameters I tried.
This week I tried to get it up-and-running again. Mainly because I can't concentrate for longer than two hours for my Cisco exams next week. Sometimes you need to clear your head.
For some reason I found the solution within the hour. No idea what the original problem was exactly.
It's been three weeks exactly (well, almost), and my new iMac i7 27" went to the repair shop.. (*sniff*).
The iMac booted normally this morning, but after a couple of minutes, the fans started kicking in. A new sensation for me. I have never heard a fan in this, or my other (i)Macs. At first I thought that my external drive (Drobo) started making the noise, but the Drobo was silent.
Turned out the fans in my iMac started blowing (hard), and the airflow was relatively warm. Too warm for a Mac which has been switched on for about 10 minutes with no real CPU intensive tasks running.
First I checked the Activity Monitor and 'Top' in the Terminal app to see if there was some program that consumed too many CPU cycles. Nothing there. On average, the CPU was 3% busy.
Next thing to do was resetting the PRAM/NVRAM by holding the Option-Command-R-P combination during a power-on of the iMac. This also made no difference (booting went a bit faster though).
One can not have enough screen "real-estate" when working with photos, or while exploring your web-development skillz. So, a single display is simply not an option in my case......
Next to my 27" iMac stands a Dell 24" TFT Display. This Dell display is being abused for two things;
using the input selector on the TFT display.
Since I'm a guy and I rock at multitasking (*cough*), I have both my Windows (work) laptop and my iMac powered on. In this scenario I have only one active display on my iMac. The second display should therefor not be used, and this is where Apple fails miserably.
There's probably more than enough information on this subject, but there's something I ran into;
After the iOS 4.2 update, I also got a iPhone Carrier update through iTunes, and brave as I am, I installed it.
Afterward, several options in the Settings -> General -> Carrier menu of the iPhone were gone. Specifically, the settings regarding the Cellular Data settings, MMS. Basically, all the stuff I had to do manually as described in this blogpost.
Apple must have included the KPN Carrier settings in their Carrier Support package. Checking the default carrier profile location (/Users//Library/iTunes/iPhone Carrier Support/) showed the KPN_nl_iPhone.ipcc profile.
This does make it easier to upgrade to another iOS version, because each earlier upgrade erased the settings I had entered manually the time before. On the downside; The profile could also be updated to remove/disable tethering on the iPhone on the KPN network.
The ipcc file mentioned earlier is the one distributed on (or around) November 24th, 2010.
For the last 5 years, I've been using the Apple iPhoto application to create my holiday photo albums (five so far). Some might find them too expensive, but I simply love the Apple iPhoto integration, the available templates, and ordering process. Worth every penny in my opinion.
The 46 page photo album of the Spain holiday arrived today. Time between ordering and delivery was thee work days (five if you include the weekend). Excellent, fast, service if I may say so.
The album was created with Apple iPhoto.
Warning: crappy low-light iPhone photo :-)Thankfully, the real thing looks much better.......
The photos seen in the album in the photo above is a 7 photo panoramic overview of Granada, Spain. Taken from within Alhambra.
I ran into a problem with MMS after I upgraded to iOS4 on my iPhone 3GS. Somehow, it was impossible to send MMS messages on the KPN cellular network. Searching the Internet revealed that I wasn't the only one.
The general consensus to solve this issue was a restore of the iPhone and not to restore old settings, but start from scratch.
After doing this, MMS still couldn't be sent from the iPhone, so time to do some more research. It turned out that KPN must have change the MMS settings, since my old MMS settings weren't correct anymore. So try these settings BEFORE you restore your iPhone. It might save you a lot of work and time.
Note: the following settings are for the Dutch KPN Network, and probably won't work on other networks / carriers.
APN: portalmmm.nl
Username:
Password:
MMSC: http://mp.mobiel.kpn/mmsc
MMS Proxy: 10.10.100.50:5080
MMS Max Message Size: 300000
APN: portalmmm.nl
Username: kpn
Password: kpn
MMSC: http://mp.mobiel.kpn/mmsc
MMS Proxy: 10.10.100.20:5080
MMS Max Message Size: <leave empty>
Notice the differences? Anyway, with these new settings, MMS worked again.
KPN does have a page dedicated to the iPhone (in Dutch), regarding the Internet, and MMS settings. Just check those pages for the lastest settings.
I've updated the original page on my blog with the new settings.
Ever since I switched to OS X server at home I use Splunk> to see what's happening 'underneath the hood'. This revealed that there's a lot (really a whole lot) of Kerberos logging going on. Each and every day I get thousands of log entries regarding krb5kdc which results in over 1 million log entries only for krb5kdc in little over a week.
These syslog messages only contain the following 'text';
krb5kdc[16179](debug): routing msg not interesting
krb5kdc[16179](info): got routing msg type 5(RTM_LOSING) v5
krb5kdc[16179](info): routing socket readable
Looks like that the debugging level is set to debug (why??). And why can't we change it? Others seem to have this problem as well.
Looks like that the following command seems to work:
sudo defaults write /Library/Preferences/DirectoryService/DirectoryServiceDebug "Debug Logging Priority Level" FALSE
After entering that 1 line I haven't seen any new logentries in the kdc logs. More info on that command can be found @ Apple.
Nevermind......