I've been tasked with creating a simple Moodle install package for OS X (similar to the easy install packages that exist for Windows).
I'm pretty sure I can use a combination of PackageMaker, shell scripting, and AppleScript to automate the process shown here (this is slightly different from the process given in the Moodle installation wiki).
Here's the flow I have in mind:
1. Open mpkg file containing Liyanage PHP package, MySQL, and Moodle.
2. Install PHP (AppleScript or shell script).
3. Install MySQL (AppleScript or shell script)
4. Create MySQL users, databases, etc (shell script does this, using AppleScript to prompt for passwords for the the MySQL root user and the Moodle user).
5. Unpack Moodle into the proper place (/Library/WebServer/Documents), along with a pre-written config.php file (shell script)
6. Create a Moodle data folder and give it the correct permissions (shell script).
7. Use perl or PHP to stick the right user info for the database in config.php.
8. Turn Apache on (shell script).
9. Launch browser and point it at the Moodle install (shell script or AppleScript).
Does anyone see an important step I'm leaving out?
This should definitely check to see if Apache and MySQL are running beforehand, and refuse to proceed if they are. I definitely don't want to clobber any existing stuff.
If this is done properly, all the shell script stuff should be invisible to the user. All he or she will see is a couple of prompts for setting passwords.
Wonderful plan! As you know, OS X servers are rated #1 by InfoWorld and there is an unexpected booming growth for them.
One question, have you investigated the OS X packages by Server Logistics? They include Apache 2.0.52, MySQL 4.0.21, and PHP 4.3.9 with a built-in TurckMM PHP accelerator. The packages install outside of Apple's Apache and turn it off.
I imagine this SL plan would take longer to set up than your Liyanage plan with Apple's Apache I.x.x. Are there any advantages to Apache 2? Any risks in including a PHP accelerator?
One question, have you investigated the OS X packages by Server Logistics? They include Apache 2.0.52, MySQL 4.0.21, and PHP 4.3.9 with a built-in TurckMM PHP accelerator. The packages install outside of Apple's Apache and turn it off.
I imagine this SL plan would take longer to set up than your Liyanage plan with Apple's Apache I.x.x. Are there any advantages to Apache 2? Any risks in including a PHP accelerator?
One question, have you investigated the OS X packages by Server Logistics?
Nope, I haven't tried any of their stuff, but I'll be sure to have a look. I'm not sure that there's any real advantage to Apache2 for running Moodle, especially since that would mean one more package to upgrade (the built-in OS X Apache gets updated by Apple's software update, as you probably know).
The built-in PHP accelerator sounds nice, though. I had Turck running on our server for a while, but never got around to reinstalling it after a PHP upgrade. I didn't experience any problems with it.
We'd like to come up with a package that an instructor with a Mac could install really fast in order to evaluate Moodle (and maybe teach a class or two).
Nope, I haven't tried any of their stuff, but I'll be sure to have a look. I'm not sure that there's any real advantage to Apache2 for running Moodle, especially since that would mean one more package to upgrade (the built-in OS X Apache gets updated by Apple's software update, as you probably know).
The built-in PHP accelerator sounds nice, though. I had Turck running on our server for a while, but never got around to reinstalling it after a PHP upgrade. I didn't experience any problems with it.
We'd like to come up with a package that an instructor with a Mac could install really fast in order to evaluate Moodle (and maybe teach a class or two).
Tony,
This is fantastic news, and it looks like you've got everything. I'm sure you'll find out for sure soon enough
A few questions:
1. Is there anything for the cron job? A cute little MoodleCron4Mac would be nice I'm willing to pay to have this made into a cocoa app
2. Just out of curiosity, where are you putting the moodledata/ folder?
Keep up the great work! --Mark
This is fantastic news, and it looks like you've got everything. I'm sure you'll find out for sure soon enough
A few questions:
1. Is there anything for the cron job? A cute little MoodleCron4Mac would be nice
2. Just out of curiosity, where are you putting the moodledata/ folder?
Keep up the great work! --Mark
Good point. Setting up the cron job could be another task for the shell script.
It'd be easy enough to create something like the Moodle cron for Windows, but since the Mac has a real cron, why not use it?
Have you seen Cronnix? Lots of people seem to like that.
I usually just toss the moodle data folder in the root folder of the HD so it's easy to find, but it should probably go somewhere else (especially if the machine isn't a dedicated Moodle server). Putting it in some quasi-standard Unixy location like /usr/local/moodle/data would make it hard to use with the Finder. Hmmm..
Thanks!
It'd be easy enough to create something like the Moodle cron for Windows, but since the Mac has a real cron, why not use it?
Have you seen Cronnix? Lots of people seem to like that.
I usually just toss the moodle data folder in the root folder of the HD so it's easy to find, but it should probably go somewhere else (especially if the machine isn't a dedicated Moodle server). Putting it in some quasi-standard Unixy location like /usr/local/moodle/data would make it hard to use with the Finder. Hmmm..
Thanks!
the Mac has a real cron
Of course for your installer, I agree 100%. I'm talking about a separate .app Cronnix is great, but it's overkill for Moodle's purposes A simple .app like the MoodleCron4Windows wrapped in, how did you once say it?, "sweet OSX aqua-flavoured goodness" would be ideal
On the other hand, I don't know who would need it after your great installer is finished
Of course for your installer, I agree 100%. I'm talking about a separate .app
On the other hand, I don't know who would need it after your great installer is finished
I usually just toss the moodle data folder in the root folder of the HD so it's easy to find, but it should probably go somewhere else (especially if the machine isn't a dedicated Moodle server). Putting it in some quasi-standard Unixy location like /usr/local/moodle/data would make it hard to use with the Finder. Hmmm..
Well I am not sure if OSX has a defined filesystem hierachy, but you better stick to the standard unix location. OSX is not unixy, it IS unix. using non-standard locations because that makes it easier to use with some application makes no sense at all. Every developer tries to make life easy for the user and admin, one way is not making a mess of the filesystem layout.
Well I am not sure if OSX has a defined filesystem hierachy
It does, actually.
OSX is not unixy, it IS unix.
Well, sort of. It's more like "Unix Plus".
The problem here is that you can't browse to /usr with the GUI Finder, you have to get there through the command line. The GUI only lets you browse to places where a "normal" user should be able to go, not to places where system files are kept.
For example, on my own machine the Finder shows me Applications, Developer, Library, moodledata, sw (used by Fink), System, and Users. My personal files are under Users/tonyhursh, rather than /home/tonyhursh as they would be on most Linux systems.
If I go out to tcsh, on the other hand, I see:
Applications
Desktop DB
Desktop DF
Developer
Library
Network
System
Temporary Items
Users
Volumes
automount
bin
cores
dev
etc
hosted
linux1
mach
mach.sym
mach_kernel
moodledata
opt
private
sbin
sw
tmp
usr
var
Much more like a standard Unix system.
This actually makes a lot of sense for most things, but could pose a problem for Moodlers who need to get into their data folders using the GUI finder.
I think Daryl Hawes' suggestion is probably what we'll go with. This whole thing is on hold until the end of the semester most likely.
It does, actually.
OSX is not unixy, it IS unix.
Well, sort of. It's more like "Unix Plus".
The problem here is that you can't browse to /usr with the GUI Finder, you have to get there through the command line. The GUI only lets you browse to places where a "normal" user should be able to go, not to places where system files are kept.
For example, on my own machine the Finder shows me Applications, Developer, Library, moodledata, sw (used by Fink), System, and Users. My personal files are under Users/tonyhursh, rather than /home/tonyhursh as they would be on most Linux systems.
If I go out to tcsh, on the other hand, I see:
Applications
Desktop DB
Desktop DF
Developer
Library
Network
System
Temporary Items
Users
Volumes
automount
bin
cores
dev
etc
hosted
linux1
mach
mach.sym
mach_kernel
moodledata
opt
private
sbin
sw
tmp
usr
var
Much more like a standard Unix system.
This actually makes a lot of sense for most things, but could pose a problem for Moodlers who need to get into their data folders using the GUI finder.
I think Daryl Hawes' suggestion is probably what we'll go with. This whole thing is on hold until the end of the semester most likely.
Hi Tony, I'd guess most Mac users would be installing in /users/username/sites directory by default.
Perhaps you could set the installer to create moodledata in users/username/moodledata, since the installing user will have full access to that folder.
Maybe an expert option could suggest full administrators to install in Library/Webserver/Documents/ and allow themt to put the data directory anywhere they like (assuming that admins will be running OSX server or have figured out how to add a root user to their client install, would know enought to put their data directory in a good place.
Perhaps you could set the installer to create moodledata in users/username/moodledata, since the installing user will have full access to that folder.
Maybe an expert option could suggest full administrators to install in Library/Webserver/Documents/ and allow themt to put the data directory anywhere they like (assuming that admins will be running OSX server or have figured out how to add a root user to their client install, would know enought to put their data directory in a good place
Michael,
As I have noted in the Moodle on Mac OS X install document posted in the support forums I strongly recommend against installing in the user's home folder. Whether you are on client or server you should not be installing into the user's home folder but rather into the appropriate "local" level folder. imho Moodle should be installed in /Library/Webserver/Documents/moodle and moode's data folder should be at /Library/Webserver/moodledata. This is fairly good Unix practice and as discussed here Mac OS X is based on Unix.
Further the installer mechanism on Mac OS X does NOT allow you to install anything into the /Users area. It's not meant to install prefs and other support files, it's meant to install applications and the like - none of which can be targeted at a user's home directory using the PackageMaker application.
Daryl
As I have noted in the Moodle on Mac OS X install document posted in the support forums I strongly recommend against installing in the user's home folder. Whether you are on client or server you should not be installing into the user's home folder but rather into the appropriate "local" level folder. imho Moodle should be installed in /Library/Webserver/Documents/moodle and moode's data folder should be at /Library/Webserver/moodledata. This is fairly good Unix practice and as discussed here Mac OS X is based on Unix.
Further the installer mechanism on Mac OS X does NOT allow you to install anything into the /Users area. It's not meant to install prefs and other support files, it's meant to install applications and the like - none of which can be targeted at a user's home directory using the PackageMaker application.
Daryl
I have about 4 Moodle's installed on my XServe, all of them in /~user. Why is this a problem? Isn't this where OSX (and Unix) expects you to put user's web pages?
I certainly don't want /~user to be ftping into Webserver/Documents/ and I'd rather have the OS manage the permisssions rather than have to set them up for a new user in / every time I install a new Moodle.
I certainly don't want /~user to be ftping into Webserver/Documents/ and I'd rather have the OS manage the permisssions rather than have to set them up for a new user in / every time I install a new Moodle.
(assuming that admins will be running OSX server or have figured out how to add a root user to their client install)
Another little note: root is not enabled on Mac OS X client for a reason. You can do pretty much everything with Finder and sudo you would need root for. The PackageMaker app also allows you to install anywhere with root privs if required - the user just needs to authenticate as an admin.
Another little note: root is not enabled on Mac OS X client for a reason. You can do pretty much everything with Finder and sudo you would need root for. The PackageMaker app also allows you to install anywhere with root privs if required - the user just needs to authenticate as an admin.
If someone takes the time to enable root on OSX client they should have a reason for it and be able to handle the responsibility.
If someone takes the time to enable root on OSX client they should have a reason for it and be able to handle the responsibility.
Michael, I kindly beg to differ with your statement. Enabling the root user on Mac OS X client is a relatively easy process, if a somewhat hidden one. With sites like macosxhints.com and numerous blogs as well as Apple's knowledge base detailing the steps it's simple for someone without the need to go ahead and enable root. Some administrators I have met who were very comfortable with managing Mac OS 7/8/9 machines found themselves in a bind with limited capabilities - so instead of learning about sudo, Pseudo and other tools, they log into their systems as the root user for ordinary tasks such as software updates, etc. I cannot stress enough how poor an idea it is to login to Finder as root to perform mundane sysadmin tasks.
Michael, I kindly beg to differ with your statement. Enabling the root user on Mac OS X client is a relatively easy process, if a somewhat hidden one. With sites like macosxhints.com and numerous blogs as well as Apple's knowledge base detailing the steps it's simple for someone without the need to go ahead and enable root. Some administrators I have met who were very comfortable with managing Mac OS 7/8/9 machines found themselves in a bind with limited capabilities - so instead of learning about sudo, Pseudo and other tools, they log into their systems as the root user for ordinary tasks such as software updates, etc. I cannot stress enough how poor an idea it is to login to Finder as root to perform mundane sysadmin tasks.
The problem here is that you can't browse to /usr with the GUI Finder, you have to get there through the command line.
This is not entirely true Tony.
In the Finder press command-shift-G or choose "Go to folder.." from the "Go" menu. Type any unix path into the dialog that appears, such as "/usr", and you will be able to navigate through that area (even behind a "hidden" folder).
Daryl
This is not entirely true Tony.
In the Finder press command-shift-G or choose "Go to folder.." from the "Go" menu. Type any unix path into the dialog that appears, such as "/usr", and you will be able to navigate through that area (even behind a "hidden" folder).
Daryl
Didn't know about that one. Thanks!
If OSX has a standard about the filesystem hierachy, then it should tell you where to put your packages, shouldn't it?
If your finder chooses to filter what you can see of the filesystem (which is quite reasonable) then maybe your installer can make some symlinks to the real location?
If your finder chooses to filter what you can see of the filesystem (which is quite reasonable) then maybe your installer can make some symlinks to the real location?
Uh, for the clueless: which moodle cron jobs should I be running?
You might find some answers in the Mac OS X install wiki.
http://moodle.org/wiki/index.php/InstallingMoodle
Feel free to update and put your name next to any changes or additions you made in case I need to get back to you about questions. Thanks!
http://moodle.org/wiki/index.php/InstallingMoodle
Feel free to update and put your name next to any changes or additions you made in case I need to get back to you about questions. Thanks!
Ack! The wiki has been spammed again.
I'll fix some of them now. Maybe others can fix the rest if they get time.
I'll fix some of them now. Maybe others can fix the rest if they get time.
Tony,
great plan. I am very interested in hearing of your experience using PackageMaker, specially wrt to automating the creation of new versions of the package.
I've promised I'd package eXe -- a Moodle-related project more info at http://eduforge.org/projects/exe -- for the Mac, and I'm still undecided, doubting between PackageMaker and Fink. In the case of package maker, I'd make a Fink package and distribute Fink +my package + dependencies. The fink route makes things easier for long-term maintenance, and has all the dependencies covered.
Fink package-building is all commandline, so it's really easy to automate with a bit of bash. Actually, it's all Perl, so I can get to the guts of it riding the camel.
PackageMaker is great for GUI apps, but is pretty dead on the water when it comes to upgrades (AFAIK) -- but this may not matter to you if it's just for test installations. If it should work as well for production servers (edit: like that massively sexy Xserver cluster you've got), I'd go for Fink. Edit: fink is often used to deploy software in large OSX clusters, with scripting techniques similar to the ones we use on our clusters at Catalyst.
There is a Debian package of Moodle, maintained by Isaac Clerencia (and very up-to-date, Isaac is using Moodle himself quite a bit). His package is a great place to start looking into if you are thinking of installing the cronjob and general installation scripts. If you use fink, it's trivial to port the Debian package to fink -- one less thing to think about. And if your package derives from his, you can always share bugfixes and enhancements.
At any rate, keep us posted on how it goes. I'll be jumping in the same waters soon ;)
great plan. I am very interested in hearing of your experience using PackageMaker, specially wrt to automating the creation of new versions of the package.
I've promised I'd package eXe -- a Moodle-related project more info at http://eduforge.org/projects/exe -- for the Mac, and I'm still undecided, doubting between PackageMaker and Fink. In the case of package maker, I'd make a Fink package and distribute Fink +my package + dependencies. The fink route makes things easier for long-term maintenance, and has all the dependencies covered.
Fink package-building is all commandline, so it's really easy to automate with a bit of bash. Actually, it's all Perl, so I can get to the guts of it riding the camel.
PackageMaker is great for GUI apps, but is pretty dead on the water when it comes to upgrades (AFAIK) -- but this may not matter to you if it's just for test installations. If it should work as well for production servers (edit: like that massively sexy Xserver cluster you've got), I'd go for Fink. Edit: fink is often used to deploy software in large OSX clusters, with scripting techniques similar to the ones we use on our clusters at Catalyst.
There is a Debian package of Moodle, maintained by Isaac Clerencia (and very up-to-date, Isaac is using Moodle himself quite a bit). His package is a great place to start looking into if you are thinking of installing the cronjob and general installation scripts. If you use fink, it's trivial to port the Debian package to fink -- one less thing to think about. And if your package derives from his, you can always share bugfixes and enhancements.
At any rate, keep us posted on how it goes. I'll be jumping in the same waters soon ;)
Fink is awesome, but won't work for this particular task. We want something we can distribute to a teacher who has a Mac in his/her classroom that the teacher can get up and running in short order. Those people aren't likely to have Fink installed.
PackageMaker is pretty easy to use, actually. You just create a mirror directory tree with all the files in the proper place, then run PackageMaker on the tree to build the package (it's a little more complicated if you need to run scripts as well as just copying files to the proper location, but not overly so). It's sort of like building an RPM, but not as ugly.
There's a good overview here.
One nice thing about PackageMaker that Fink doesn't support (I don't think... I could be wrong about this) is that PackageMaker adds the correct file permissions to the system permissions database. If file or folder permissions get screwed up, they'll be fixed if the user runs "repair permissions" in the Disk Utility.
PackageMaker is pretty easy to use, actually. You just create a mirror directory tree with all the files in the proper place, then run PackageMaker on the tree to build the package (it's a little more complicated if you need to run scripts as well as just copying files to the proper location, but not overly so). It's sort of like building an RPM, but not as ugly.
There's a good overview here.
One nice thing about PackageMaker that Fink doesn't support (I don't think... I could be wrong about this) is that PackageMaker adds the correct file permissions to the system permissions database. If file or folder permissions get screwed up, they'll be fixed if the user runs "repair permissions" in the Disk Utility.
I don't get why you'd balk at installing a package manager that takes care of all dependencies and keeping stuff up to date (does the right thing), but have no problems with installing big programs like PHP and MySQL yourself without any of those checks and bonuses (not quite the right thing).
Don't you care about the maintainabilty of your users computers? How will you make sure that you don't overwrite an existing mysql install, or how will you keep it up to date?
I would make a wrapper around testing for- and installing fink, and go from there. The bonus there is that you don't have to package php or mysql, and a port of the debain package for moodle will be pretty easy (fink uses dpkg and apt-get too, moodle has no compiled code). And the kicker is that you have created a fink package that you can give back to the comunity.
Don't you care about the maintainabilty of your users computers? How will you make sure that you don't overwrite an existing mysql install, or how will you keep it up to date?
I would make a wrapper around testing for- and installing fink, and go from there. The bonus there is that you don't have to package php or mysql, and a port of the debain package for moodle will be pretty easy (fink uses dpkg and apt-get too, moodle has no compiled code). And the kicker is that you have created a fink package that you can give back to the comunity.
Don't you care about the maintainabilty of your users computers?
Yes. That's why I want to use a PackageMaker package, which is the standard software packaging tool for this platform.
How will you make sure that you don't overwrite an existing mysql install
By making sure that /usr/local/mysql doesn't already exist. Anyone who's clever enough to have installed it elsewhere is also clever enough to not need this package.
I would make a wrapper around testing for- and installing fink, and go from there. The bonus there is that you don't have to package php or mysql,
Sorry, fink is just not an option for the audience we have in mind. Other people do a fine job of packaging mysql and php for the Mac, and installing them in a standard Mac way (i.e., a way that doesn't involve screwing around with fink or the Unix shell).
Fink is great for getting something ported over from Linux in a hurry, but it's far from ideal.
And the kicker is that you have created a fink package that you can give back to the comunity.
A PackageMaker package would be usable by several orders of magnitude more users than a fink package would be.
Yes. That's why I want to use a PackageMaker package, which is the standard software packaging tool for this platform.
How will you make sure that you don't overwrite an existing mysql install
By making sure that /usr/local/mysql doesn't already exist. Anyone who's clever enough to have installed it elsewhere is also clever enough to not need this package.
I would make a wrapper around testing for- and installing fink, and go from there. The bonus there is that you don't have to package php or mysql,
Sorry, fink is just not an option for the audience we have in mind. Other people do a fine job of packaging mysql and php for the Mac, and installing them in a standard Mac way (i.e., a way that doesn't involve screwing around with fink or the Unix shell).
Fink is great for getting something ported over from Linux in a hurry, but it's far from ideal.
And the kicker is that you have created a fink package that you can give back to the comunity.
A PackageMaker package would be usable by several orders of magnitude more users than a fink package would be.
(i.e., a way that doesn't involve screwing around with fink or the Unix shell).
Well, there is Fink Commander.
Well, there is Fink Commander
Seriously, the thing I like most about OS X is the general ease and cleanness with which applications can be installed or moved around (of course, there are exceptions, but mostly you can drag an application anywhere you want and it Just Works)
Using fink lets one revisit the horrors of Library Hell (DLL Hell/RPM Hell) that we've all enjoyed under Linux and/or Windows.
I like fink and use it a lot, but whenever I try to install something and get 50 library conflicts, I really wonder how I put up with that crapola for so many years with Linux.
There are many things to admire about Linux, but the software packaging and distribution mechanism is not one of those things.
Tony Hursh:
Your Linux experences differ very much from mine. I stick to Debian sarge, and have _never_ encountered any library conflicts whatsoever. When I used Fedora or redhat i had to use apt-rpm to get out of rpm-hell. Because there were fewer people contributing to (and testing) those repositories, an error would occur once in a while. That is where the large developerbase of Debian pays of.
Fink is [a direct descendant of/build on] apt, so the tools are very similar. But if the repository is not maintained with the same diligence, you can very well run into problems. Or were you using some experimental/unstable repositories?
Anyway, I recently read somewhere that OSX package manager does not do dependency checking, and has no support for deleting packages(without breaking others). I definitely would choose rpm(or dpkg) hell over 'figure it out yourself and pray the developer didn'y mess up'. But I prefer apt on top of that.
There are many things I admire about Debian, and the software packaging and distribution system they have build/maintain is certainly one of them.
Using fink lets one revisit the horrors of Library Hell (DLL Hell/RPM Hell) that we've all enjoyed under Linux and/or Windows.
I like fink and use it a lot, but whenever I try to install something and get 50 library conflicts, I really wonder how I put up with that crapola for so many years with Linux.
There are many things to admire about Linux, but the software packaging and distribution mechanism is not one of those things.
Your Linux experences differ very much from mine. I stick to Debian sarge, and have _never_ encountered any library conflicts whatsoever. When I used Fedora or redhat i had to use apt-rpm to get out of rpm-hell. Because there were fewer people contributing to (and testing) those repositories, an error would occur once in a while. That is where the large developerbase of Debian pays of.
Fink is [a direct descendant of/build on] apt, so the tools are very similar. But if the repository is not maintained with the same diligence, you can very well run into problems. Or were you using some experimental/unstable repositories?
Anyway, I recently read somewhere that OSX package manager does not do dependency checking, and has no support for deleting packages(without breaking others). I definitely would choose rpm(or dpkg) hell over 'figure it out yourself and pray the developer didn'y mess up'. But I prefer apt on top of that.
There are many things I admire about Debian, and the software packaging and distribution system they have build/maintain is certainly one of them.
Your Linux experences differ very much from mine.
Yeah, it sounds like they do.
Anyway, I recently read somewhere that OSX package manager does not do dependency checking, and has no support for deleting packages(without breaking others).
Most true OS X applications are application bundles, so conflicts per se aren't generally an issue. Breaking one userland application by installing another just doesn't happen.
The overwhelming advantage of application bundles is that applications can be dragged and dropped anywhere and they just work. All of their state is inside the bundle, not scattered across twenty libraries and fifteen config files. This also makes it much easier to have multiple versions of an app installed for testing purposes.
The traditional advantages of separate libraries are much less compelling nowadays, when people can have hundreds of gigs of disk space and a gig or two of RAM in a desktop machine. About the only thing a separate library really buys you in the modern world is the ability to update the library separately from the application. This can be somewhat useful if, say, a security flaw is discovered in a library; you can update the library and (in theory) all the installed apps that use that library will be patched without needing to reinstall them. In practice, updating libraries often breaks things.
Of course, the real issue here is that probably 85-90% of Mac users don't have fink, don't know what fink is, and wouldn't use fink even if they did know about it. I really can't blame them for that one bit.
I'd have to say that I agree with most of what Sean Russell says in this essay.
Yeah, it sounds like they do.
Anyway, I recently read somewhere that OSX package manager does not do dependency checking, and has no support for deleting packages(without breaking others).
Most true OS X applications are application bundles, so conflicts per se aren't generally an issue. Breaking one userland application by installing another just doesn't happen.
The overwhelming advantage of application bundles is that applications can be dragged and dropped anywhere and they just work. All of their state is inside the bundle, not scattered across twenty libraries and fifteen config files. This also makes it much easier to have multiple versions of an app installed for testing purposes.
The traditional advantages of separate libraries are much less compelling nowadays, when people can have hundreds of gigs of disk space and a gig or two of RAM in a desktop machine. About the only thing a separate library really buys you in the modern world is the ability to update the library separately from the application. This can be somewhat useful if, say, a security flaw is discovered in a library; you can update the library and (in theory) all the installed apps that use that library will be patched without needing to reinstall them. In practice, updating libraries often breaks things.
Of course, the real issue here is that probably 85-90% of Mac users don't have fink, don't know what fink is, and wouldn't use fink even if they did know about it. I really can't blame them for that one bit.
I'd have to say that I agree with most of what Sean Russell says in this essay.
>>Most true OS X applications are application bundles, so conflicts per
se aren't generally an issue. The overwhelming advantage of application bundles is that applications
can be dragged and dropped anywhere and they just work. All of their
state is inside the bundle, not scattered across twenty libraries and
fifteen config files. This also makes it much easier to have multiple
versions of an app installed for testing purposes.
Thanks, Tony, for explaining this. Now I understand why I could easily work with OS X, and why I couldn't understand Linux installations (libraries and config files). Thanks also for working on this Mac Install Disk. I will be a big user when it comes out.
Thanks, Tony, for explaining this. Now I understand why I could easily work with OS X, and why I couldn't understand Linux installations (libraries and config files). Thanks also for working on this Mac Install Disk. I will be a big user when it comes out.
What you say about OSX application bundles is true. The complex packaging tools in Debian and similar Linux distribution are a must for OS and infrastructure, they give you the hooks for clean upgrades, library maintenance, efficient disk and RAM usage, etc.
NeXT/OSX app bundles are 'easy' and yet are forced to pack all their dependencies. There's no upgrade hooks, no meaningful way for them to handle dependencies or, most importantly, conflicts. They are OK for casual users performing installs on top of their OS, but sub-par for professionally managed server environments.
That's why we use Debian ;) and also why institutions with large OSX deployements (desktop or server) use fink extensively.
NeXT/OSX app bundles are 'easy' and yet are forced to pack all their dependencies. There's no upgrade hooks, no meaningful way for them to handle dependencies or, most importantly, conflicts. They are OK for casual users performing installs on top of their OS, but sub-par for professionally managed server environments.
That's why we use Debian ;) and also why institutions with large OSX deployements (desktop or server) use fink extensively.
Wandering way of topic here...
One thing that might be a nice extension to apt-get, would be an easier integration with 3-rd party vendors. So you install a 3rd party package, and it asks you if you want apt to check for updates for it.
And a way to install single packags with apt, so you just click on the package, and apt installs the missing libraries (similar to doing a apt-get install, but now the actual package is not in the repository).
And a way to track where each installed package came from would be nice too.
But all these things would move away from the 'one big repository for everything' so I don't think it will happen anytime soon.
One thing that might be a nice extension to apt-get, would be an easier integration with 3-rd party vendors. So you install a 3rd party package, and it asks you if you want apt to check for updates for it.
And a way to install single packags with apt, so you just click on the package, and apt installs the missing libraries (similar to doing a apt-get install, but now the actual package is not in the repository).
And a way to track where each installed package came from would be nice too.
But all these things would move away from the 'one big repository for everything' so I don't think it will happen anytime soon.
I hope you have a good GPS (or a good compas, sextant, reduction tables and mathemathics skils) because you are waaaaay of base claiming that libraries are a thing of the past nad not yet needed anymore. I would venture you live somewhere on the other side of the world by now
Libraries not only save disk space, they also make maintainance a lot easier: Imagine a security leak in libc (the big library nearly every program is linked against). A typical server easily reaches 1000 executables. If everything were statically linked, you would need to upgrade every single one of those 1000 programs. How would you like to have to manually download those 1000 program bundles (ok they are bundles, so maybe less then 1000) that are incidentally much bigger than needed because they are statically linked. 1 Gb for a lousy security fix?
This is indeed a bit overstated, but you will probably get the point. Libraries are there for a good reason, and that is more than saving diskspace (it saves RAM too, did I say that yet?).
Rpm and dpkg are the solution to (library) dependencies and apt-get is the debian solution to rpm-hell.
Libraries not only save disk space, they also make maintainance a lot easier: Imagine a security leak in libc (the big library nearly every program is linked against). A typical server easily reaches 1000 executables. If everything were statically linked, you would need to upgrade every single one of those 1000 programs. How would you like to have to manually download those 1000 program bundles (ok they are bundles, so maybe less then 1000) that are incidentally much bigger than needed because they are statically linked. 1 Gb for a lousy security fix?
This is indeed a bit overstated, but you will probably get the point. Libraries are there for a good reason, and that is more than saving diskspace (it saves RAM too, did I say that yet?).
Rpm and dpkg are the solution to (library) dependencies and apt-get is the debian solution to rpm-hell.
hope you have a good GPS (or a good compas, sextant, reduction tables and mathemathics skils) because you are waaaaay of base claiming that libraries are a thing of the past nad not yet needed anymore.
Jelle, I don't want to have a lengthy (and off-topic) argument about this. Your libc example is a complete red herring, since no one distributes libc with application programs. The OS X C runtime library is distributed by Apple and gets updated by their own software update procedure.
It's also an extremely poor example since (as you say) it's used by so many different programs. That is not the case for (to take a realistic example) the libogg and libvorbis files for decoding Ogg Vorbis files. Only a few programs use those, and you're very unlikely to have more than one or two of them running at the same time. Even if you do, so what? They're maybe 100K or so at most. There's absolutely no reason for these to be system libraries.
Apple (and previously, NeXT) could certainly have used the traditional Unix library model, rather than developing the application bundle, had they so chosen. They didn't do that. Maybe you should ask yourself if perhaps they had a good reason (hint: it wasn't because they were amateurs who didn't know what they were doing).
Anyway, all of this is irrelevant for the application at hand, which is to develop a Moodle install bundle that a TYPICAL Mac OS X user can install and use without jumping through hoops. Fink isn't the answer for that problem. It just isn't.
Jelle, I don't want to have a lengthy (and off-topic) argument about this. Your libc example is a complete red herring, since no one distributes libc with application programs. The OS X C runtime library is distributed by Apple and gets updated by their own software update procedure.
It's also an extremely poor example since (as you say) it's used by so many different programs. That is not the case for (to take a realistic example) the libogg and libvorbis files for decoding Ogg Vorbis files. Only a few programs use those, and you're very unlikely to have more than one or two of them running at the same time. Even if you do, so what? They're maybe 100K or so at most. There's absolutely no reason for these to be system libraries.
Apple (and previously, NeXT) could certainly have used the traditional Unix library model, rather than developing the application bundle, had they so chosen. They didn't do that. Maybe you should ask yourself if perhaps they had a good reason (hint: it wasn't because they were amateurs who didn't know what they were doing).
Anyway, all of this is irrelevant for the application at hand, which is to develop a Moodle install bundle that a TYPICAL Mac OS X user can install and use without jumping through hoops. Fink isn't the answer for that problem. It just isn't.
Tony,
I have gone ahead and worked something up. I was inspired by Eloy's work on an automated xampp for Windows package. To see the results as they stand at the moment download http://www.cocoaojbects.com/moodle4osx.dmg and run the installer. This is the new xampp for Mac OS X installer together with moodle and the mysql admin folder. It all installs into /Applications/xampp which makes cleanup quite simple. Thoughts?
I have gone ahead and worked something up. I was inspired by Eloy's work on an automated xampp for Windows package. To see the results as they stand at the moment download http://www.cocoaojbects.com/moodle4osx.dmg and run the installer. This is the new xampp for Mac OS X installer together with moodle and the mysql admin folder. It all installs into /Applications/xampp which makes cleanup quite simple. Thoughts?
Hi Daryl
Shouldn't this be: http://www.cocoaobjects.com/moodle4osx.dmg
possibly a case of the right hand being slightly faster than the left on the keyboard?
Great work. Unfortunately, I don't have a Mac, but I know a man who does
Shouldn't this be: http://www.cocoaobjects.com/moodle4osx.dmg
possibly a case of the right hand being slightly faster than the left on the keyboard?
Great work. Unfortunately, I don't have a Mac, but I know a man who does
Correct. Sorry for the type-o.
Daryl
Where is this Automated Xampp for Windows pacakge that Eloy has created. I would like to link to that from my Moodle for Windows site.
Thanks
Never mind I found the link.
Awesome! Behold the power of procrastination!
I'll have a look at this when I'm back in the office next week.
Thanks!
I'll have a look at this when I'm back in the office next week.
Thanks!
Other people do a fine job of packaging mysql and php for the Mac
Speaking of, has anyone else noticed that Apple has (finally) started updating PHP in the standard Software Update for OS X Client?
It's actually a fairly recent build. In fact, it's the same version of PHP 4 that Marc Liyanage is providing in his package, and more recent than the version that Server Logistics has in their package.
If Apple keeps this up, there's really no reason to install a third-party PHP package (unless you need PHP 5 for some reason).
Speaking of, has anyone else noticed that Apple has (finally) started updating PHP in the standard Software Update for OS X Client?
It's actually a fairly recent build. In fact, it's the same version of PHP 4 that Marc Liyanage is providing in his package, and more recent than the version that Server Logistics has in their package.
If Apple keeps this up, there's really no reason to install a third-party PHP package (unless you need PHP 5 for some reason).
Strike that. No GD included.
Really? When did that happen? What version now? So anyone with a Moodle system running on an Apple client PHP would have had the PHP overwritten by Software Update and any modifications cleared.
When did that happen?
I don't know. I just happened to be running some PHP stuff from the command line and noticed that the version had been bumped. It's now 4.3.10.
The Apple PHP update won't interfere the Liyanage PHP package, because Apple's goes into /usr/bin/php and Liyanage goes into /usr/local/php. The Apache httpd.conf specifies which one to use so if you're using Liyanage nothing will change.
I seem to recall that you're using the Server Logistics package, though. I don't know how that one is set up.
I don't know. I just happened to be running some PHP stuff from the command line and noticed that the version had been bumped. It's now 4.3.10.
The Apple PHP update won't interfere the Liyanage PHP package, because Apple's goes into /usr/bin/php and Liyanage goes into /usr/local/php. The Apache httpd.conf specifies which one to use so if you're using Liyanage nothing will change.
I seem to recall that you're using the Server Logistics package, though. I don't know how that one is set up.
Here's the context:
The students in our on-line M.Ed. program [blatant plug] which is currently accepting applications [/blatant plug] complete a major project in EPsy 556, Analysis of Advanced Instructional Technologies. In the past, this has generally been a multimedia project, though the students are free to suggest other project topics (we strongly encourage them to pick projects that are of direct use in their own classrooms).
Next time we want to give them the option of setting up a Moodle server and doing "something" with it (for some value of "something" that's yet to be determined). The students who have Windows machines can use one of the excellent packages put together by Floyd Collins, Daryl Hawes, and others. A lot of our students use Macs, though. It'd be great to let them have the same opportunity.
While they become quite familiar with classroom technology in our program, they're still fundamentally teachers, not techies. I don't think an install that requires them to fool around with the Unix command line is going to do the job.
Naturally, if we get this working the package will be available for anyone to use, not just our students.
The students in our on-line M.Ed. program [blatant plug] which is currently accepting applications [/blatant plug]
Next time we want to give them the option of setting up a Moodle server and doing "something" with it (for some value of "something" that's yet to be determined). The students who have Windows machines can use one of the excellent packages put together by Floyd Collins, Daryl Hawes, and others. A lot of our students use Macs, though. It'd be great to let them have the same opportunity.
While they become quite familiar with classroom technology in our program, they're still fundamentally teachers, not techies. I don't think an install that requires them to fool around with the Unix command line is going to do the job.
Naturally, if we get this working the package will be available for anyone to use, not just our students.
Tony,
Here are some thoughts and resources for you to consider.
Apple's Developer Connection section on the concept of software distribution:
http://developer.apple.com/documentation/DeveloperTools/Conceptual/SoftwareDistribution/index.html?http://developer.apple.com/documentation/DeveloperTools/Conceptual/SoftwareDistribution/Concepts/sd_modify_install_ui.html
I do not recommend using AppleScript, you would be better off using a shell script. From the software distribution section please review the section about pre and post processing scripts:
http://developer.apple.com/documentation/DeveloperTools/Conceptual/SoftwareDistribution/index.html?http://developer.apple.com/documentation/DeveloperTools/Conceptual/SoftwareDistribution/Concepts/sd_modify_install_ui.html
I advise that you avoid any user interaction at the installer phase at all. Instead write an AppleScript Studio or Cocoa app to manage the installation and install it in /Applications during the install process.
/Library/WebServer/Documents/moodle is a fine installation location for the moodle files. For the dataroot I recommend creating /Library/WebServer/moodledata owned by www:admin with permissions of 775 or 770.
As you create test builds you will want to troubleshoot:
http://developer.apple.com/documentation/DeveloperTools/Conceptual/SoftwareDistribution/Concepts/sd_trouble_shooting.html#//apple_ref/doc/uid/20001946
And one last useful on topic page:
http://developer.apple.com/documentation/DeveloperTools/Conceptual/ToolsOvr_Book/DevProcess/chapter_4_section_7.html
Good luck - I'm happy to offer what assistance I can.
Here are some thoughts and resources for you to consider.
Apple's Developer Connection section on the concept of software distribution:
http://developer.apple.com/documentation/DeveloperTools/Conceptual/SoftwareDistribution/index.html?http://developer.apple.com/documentation/DeveloperTools/Conceptual/SoftwareDistribution/Concepts/sd_modify_install_ui.html
I do not recommend using AppleScript, you would be better off using a shell script. From the software distribution section please review the section about pre and post processing scripts:
http://developer.apple.com/documentation/DeveloperTools/Conceptual/SoftwareDistribution/index.html?http://developer.apple.com/documentation/DeveloperTools/Conceptual/SoftwareDistribution/Concepts/sd_modify_install_ui.html
I advise that you avoid any user interaction at the installer phase at all. Instead write an AppleScript Studio or Cocoa app to manage the installation and install it in /Applications during the install process.
/Library/WebServer/Documents/moodle is a fine installation location for the moodle files. For the dataroot I recommend creating /Library/WebServer/moodledata owned by www:admin with permissions of 775 or 770.
As you create test builds you will want to troubleshoot:
http://developer.apple.com/documentation/DeveloperTools/Conceptual/SoftwareDistribution/Concepts/sd_trouble_shooting.html#//apple_ref/doc/uid/20001946
And one last useful on topic page:
http://developer.apple.com/documentation/DeveloperTools/Conceptual/ToolsOvr_Book/DevProcess/chapter_4_section_7.html
Good luck - I'm happy to offer what assistance I can.
Hi, Daryl. I'm pretty familiar with software development and deployment on OS X.
The main application I had in mind for AppleScript was to prompt for passwords for the MySQL database, etc. You're right that most of the actual file manipulation would be better done with shell scripts, although the pkg format doesn't really require much file copying (just put it where you want it to be in the skeleton tree and that's where it'll wind up).
The main application I had in mind for AppleScript was to prompt for passwords for the MySQL database, etc. You're right that most of the actual file manipulation would be better done with shell scripts, although the pkg format doesn't really require much file copying (just put it where you want it to be in the skeleton tree and that's where it'll wind up).
This is a wonderful idea that will greatly increase the use of Moodle. I hope a windows version is in the works somewhere too.
I ended up using the server logistics php package and apache2 because I wanted support for the gdlib package and php acceleration. I recently "upgraded" to apple's latest php build because the software installer wouldn't quit nagging me. I was eventually broken to the will of apple. But I'm reinstalling the server logistics because of the acceleration.
On an unrelated note, I ran across a sourceforge project that makes precompiled php binaries. It looked intriguing, but may have been for windows.
I recently demoed Moodle at the national College Composition and Communications Conference and also talked it up to everyone I saw, and there was some definite interest, as well as a mild unfamiliarity with the European DE model (SCORM, etc.) with which many people in our little discipline are unfamiliar. But that has nothing to do with this topic!
I ended up using the server logistics php package and apache2 because I wanted support for the gdlib package and php acceleration. I recently "upgraded" to apple's latest php build because the software installer wouldn't quit nagging me. I was eventually broken to the will of apple. But I'm reinstalling the server logistics because of the acceleration.
On an unrelated note, I ran across a sourceforge project that makes precompiled php binaries. It looked intriguing, but may have been for windows.
I recently demoed Moodle at the national College Composition and Communications Conference and also talked it up to everyone I saw, and there was some definite interest, as well as a mild unfamiliarity with the European DE model (SCORM, etc.) with which many people in our little discipline are unfamiliar. But that has nothing to do with this topic!
Hi Mark,
Your experience with the Server Logistics builds for Mac OS X (by the way their are already three Windows-Moodle installers available) is very valuable.
Could you write in detail here or in the Mac OS X documentation wiki, how it the install went, what problems you had, and what to do and what to avoid? I will then pull together your comments for a little manual for others. OK?
Thanks,
Don
Your experience with the Server Logistics builds for Mac OS X (by the way their are already three Windows-Moodle installers available) is very valuable.
Could you write in detail here or in the Mac OS X documentation wiki, how it the install went, what problems you had, and what to do and what to avoid? I will then pull together your comments for a little manual for others. OK?
Thanks,
Don
Thanks to the Wiki, I tried the latest Server Logistics packages for Apache2 and PHP on my new Powerbook and they are running great. The main reason to use them is the PHP acceleration ... the difference under OS X is far more noticeable than under Linux.
First I tried adding Turck MMCache myself to the Liyanage packages that I was using, but I just ran into too many dependency issues. Switching to the SL packages made it all very easy. For everything else (aspell etc) I use Fink.
First I tried adding Turck MMCache myself to the Liyanage packages that I was using, but I just ran into too many dependency issues. Switching to the SL packages made it all very easy. For everything else (aspell etc) I use Fink.
Wouldn't it be useful to install phpMyAdmin along with everything else so that the user has a user-friendly way to access MySQL directly when the occasion calls for it?
Hmm..... that's an interesting idea. It seems like phpMyAdmin turns up with security holes on a depressingly regular basis, though (OTOH, maybe that's not suprising, considering what it lets you do).
Maybe if it were locked down so it could only be run from localhost....
It would be a nice thing to have.
Thanks for the suggestion!
Maybe if it were locked down so it could only be run from localhost....
It would be a nice thing to have.
Thanks for the suggestion!
Note that I maintain a phpmyadmin for Moodle ... it's in cvs:/mysql and you just need to drop the 'mysql' directory in moodle/admin.
I just installed OS X 10.4 and searched all over for Apache and PHP in the hidden file folders. Alas, no luck. Any idea where they are located? I am curious what changes have been made when we use this version for servers. The apache httpd.conf file looks the same, and no version number inside.