June 28, 2017, 10:42:09 PM

Author Topic: Mac OSX Server problem resolution.  (Read 2125 times)

hughf

  • Guest
Mac OSX Server problem resolution.
« on: June 27, 2011, 12:48:05 AM »
Hi Folks, my latest dissertation. Enjoy!

Mac OSX Server - Resolving a long standing problem.

You may remember several months ago my announcement of a technology change to the Mac platform in preference to my long standing use of Linux and OS/2. One of my main drivers for the change is platform integration.

I don't however intend to suggest that I have abandoned those platforms altogether as I still support clients who have relied heavily on these technologies for years. The difficulty with OS/2 is that having been unsupported by the original developer, IBM, for a number of years, it would be ludicrous to consider any further commercial development based on this platform. That immediately narrows the field for current development to Mac and Windows outside Linux. There is no escaping the practicality of the Mac for mainstream business use due to the superb OSX interface and ease of use while under the bonnet, having the versatility and flexibility of Unix from which of course Linux is derived.

My workspace had become very cluttered over time with a variety of system boxes running various operating system versions which I used for software testing and fault finding on clients' machines. I badly needed a way to get the job done reliably while reducing the clutter.

Until the advent of OSX, like many others I had considered the Mac as a niche platform which suited the creative industries exceptionally well and for which a huge software base had been developed over the years. Macs played very well with other Macs, but it was difficult to make them play well with anything else in the PC world. The principle reason was the proprietary Mac networking protocol. OSX changed that situation overnight by providing standard ethernet networking and wireless protocols in addition to the Mac AFP protocol which is now supported over ethernet.

If I then add the virtualisation capability provided by software such as Parallels and VM Fusion, I have suddenly the potential to integrate all of my development and maintenance requirements on a single hardware base; not necessarily the same machine and reduce the clutter.

Several weeks on, I'm much closer to that ideal and decided it was time to tidy up a couple of technical niggles which had been frustrating and annoying me since moving my primary server platform to Mac OSX Server.

The decision was influenced by the failure of a motherboard on my primary Linux Server which fortunately was backed up regularly to an external Lac Cie 1TB external drive over ethernet and Firewire 800.

The niggle on the surface appeared minor but was annoying in the extreme when I needed hard copy of a document shortly before heading off to a meeting or to catch a train. The problem focussed around extremely slow printing over the network from connected clients to USB printers (of which I have two) connected directly to the server. Of course, printing the document directly from the server would be instantly productive if it happened that the document existed on the server in its required form. As it happens, anything which is that current in my world probably hasn't been copied to the server at the time I need it. Better then to fix the problem.

I had consulted with Apple technical staff over the period since the original installation and from those various discussions it seemed entirely likely that when printing was initiated from a client, the server was attempting to look outside the network to find a link to the printer before it resorted to looking for it on the local network. This suggested a problem with DNS configuration. However, nobody I consulted could provide a definitive solution. Here's mine!

A closer looks revealed that there was no reverse lookup entry to allow the DNS to resolve directly to the server. As the DNS configuration requires a fully qualified domain name and my domain name is hosted by my external ISP, I reckoned that the print request was being sent to my ISP to resolve and the print delay was due to the time take for the external DNS to resolve the address or notify of failure to do so. This was the most likely scenario as the ISP's system had no way of knowing about the existence of a machine not within its own network.

Despite creating a reverse lookup manually and pinging that to my server, I was still unable to reroute print requests to a local DNS server (it didn't exist on my local sever). I decided to reinstall the server after backing up my data again via time machine  the La Cie external drive and completely reformatted the server drives before reinstalling from scratch.

At the point of deciding on a DNS server for the initial configuration, I decided to use a combination of external DNS addresses and that of my router which links to the Virgin Media network.

The next stage of installation asks that you define a fully qualified domain name and machine name. Having done so, the installation routing takes your through the remainder of the setup and creates the account for the System Administrator which you had been asked to provide details for earlier.

Following a reboot, the machine is now accessible locally from the Administrator account.

Checking revealed that the printers attached had been installed with the correct drivers by default. I don't remember it ever being that easy under Windows. However, this is the start of the problem with printing.

OSX Server, does not allow for the sharing of printers directly within the printer setup interface under System Preferences. Strange but true. You need to share the printers through the http://localhost:631 interface.

Bringing up the interface shows the printers listed as USB connections and while this appears OK, this is also where I made an alteration.

Rather than leave the printers as a direct connection to USB, I  chose 'modify printer' from the drop down menu and selected the printer name shown as a local connection. I then confirmed the modification. The printer was now shown and a local network available printer connected through a local USB port.

I repeated the process for the second printer. You can also manage the default setup for the printers from this interface and mine were set to A4 from the default US Letter format.

I returned to my Macbook Pro and cleared out the previous connections for these printers before reinstalling them. What was immediately noticeable is that the printers were located on the server instantly where before it was a long process; I suspect for the same reason as the printing delay.

Printing a test document to either printer now resulted in an instant response.

Happily I was now in the position of declaring the problem resolved and having apparently proven the critical relationship to the DNS server.

While experimenting with reinstallation (yes the fault finding and rectification process took several days), I found that changes to the DNS also could lock a user out of their data where the DNS changes related to a change in the primary domain used for reference. Due to the way the installation id configured, data storage is related to the primary domain and this is reflected in the Time Machine backup. The data is tied to the mount points of the volumes existing at the time of the backup and of course the accounts used to create the data, each file having its own permissions associated with it.

I should also mention that while it's entirely possible to partition the installation drive to maximise performance, you should be aware that splitting the operating system from services can result in a user being unable to find his home folder when logged in.

While a primary security feature of Unix based systems, it does make it difficult to regain access to your data and in fact, as the data on my Macbook Pro was actually at that time more current than the server, I copied the data directly to my data folder on the server.

As it happens, the second disk of the server, had never been used and on reinstallation I decided to utilise if for additional accounts for people now working here who had been previously assigned to the failed server.

I created folders on the second drive and assigned permissions to ensure access only by those individuals to their own folder. In Linux, this is usually achieved at the command line by the sys admin on creating the accounts but is made very straight forward by the Mac OSX interface for those not steeped in command line system administration.

I have still to reinstall a range of software which I use regularly as the server also serves as a very convenient workstation. This can't be avoided unfortunately but should take a lot less time than I have already invested in this fault resolution process.
Nevertheless, while there is a certain amount of tedium involved in the discovery process, I consider the end result worthwhile in terms of improvement in server utilisation and performance.

I should also mention as an aside for those of you who might be running Snow Leopard on Intel Processor Macs, that by default, in OSX Server, OSX installs and runs in 64 bit mode. However, on the Macbook Pro, running the client version, the default is 32 bit.

You can permanently set the default by opening Terminal and typing the following at the command line.

sudo systemsetup -setkernelbootarchitecture x86_64

Reboot the machine and you should now be running in 64 bit mode.

To check, open the system profiler and check under Software.

If you are in 64 bit mode 64 bit file extensions should read 'YES".

I hope you enjoyed the read and of course, if you have any comments or suggestions, I would be delighted to hear them.

hughf

warm

  • Guest
Re: Mac OSX Server problem resolution.
« Reply #1 on: June 29, 2011, 09:42:07 AM »

OSX Server, does not allow for the sharing of printers directly within the printer setup interface under System Preferences. Strange but true. You need to share the printers through the http://localhost:631 interface.

Bringing up the interface shows the printers listed as USB connections and while this appears OK, this is also where I made an alteration.

Rather than leave the printers as a direct connection to USB, I  chose 'modify printer' from the drop down menu and selected the printer name shown as a local connection. I then confirmed the modification. The printer was now shown and a local network available printer connected through a local USB port.

I repeated the process for the second printer. You can also manage the default setup for the printers from this interface and mine were set to A4 from the default US Letter format.

So you are using CUPS, which has been around for years, standard Linux printer serving software which apple liked so much, they bought.  Been able to do stuff like that for years, also some very nice frontends such as the KDE one.
Quote

I created folders on the second drive and assigned permissions to ensure access only by those individuals to their own folder. In Linux, this is usually achieved at the command line by the sys admin on creating the accounts but is made very straight forward by the Mac OSX interface for those not steeped in command line system administration.

Not actually used the CLI for ownership since, erm ages.  You have been able to modify permissions with a simple right click since the very first UNIX WIMP interface.  If you are running a headless machine remotely, either start up Midnight Commander, or if you prefer to do stuff in a browser with pretties, install the exceptionally powerful webmin.
 

Happy you like your OSX, I just think it is aimed at kids and posers.

[youtube]PADkpyVWAwQ[/youtube]

hughf

  • Guest
Re: Mac OSX Server problem resolution.
« Reply #2 on: July 01, 2011, 12:31:25 AM »
Warm,

The point I make relates to the fact that despite the glossy interface, unless you happen to know what will happen behind the scenes when you make decisions on setting up DNS services, you could find you have a dysfunctional installation which is difficult or impossible to rectify without a considerable degree of expertise in Unix configuration.

I found myself in that situation and thought that when I had the time, it would be instructive to clear the system down and discover just where the pitfall lay and how to avoid them.

Yes, CUPS has been a round a long time and but for the DNS fault should have worked fine but didn't until the DNS issue was rectified.

As far as creating and assigning storage for users is concerned, I didn't suggest that the CLI was needed or indeed used. I stressed the interface in the Mac OS made that task much more straight forward.

Kids and posers, Mac users may be but personally I consider that good design and accessibility to the masses is what makes for a better operating system and Apple is proving the point with every sale it makes against the PC manufacturers who don't. BTW, the only operating system bundled with a Mac if OSX but if you wish, you can run any Intel based operating system on the machine you desire together with any Intel OS supported browser  and not a sign of restrictive practice anywhere in sight. Once the customer sees and uses OSX, they have no desire to use anything else.

hughf

Offline Tomuslahm

  • Tomuslahm
  • Wee Bairn
  • *
  • Posts: 2
  • Karma: +0/-0
Re: Mac OSX Server problem resolution.
« Reply #3 on: January 25, 2016, 11:16:19 AM »
I was educated about the story with any conditions be brought under English rule. I stay fit