>> You add cpan modules into apples perl, software update comes along >> and at least has opportunity to mess with >> them. > > They don't always install properly, and even using then can cause > problems (see above).
Which is why I am advocating a stand alone install in a separate location. >> Even if you tell cpan to use something like /usr/local there have >> been 1 or 2 times Apples stomped on that area in the past as well. > > At least minimising the sources of stomping, one can stand a better > chance of keeping the box fully running. Putting software of this nature outside of a location Apple is even aware of is your best bet. I don't think you would have any issue if ASSP came in a double clickable installer, and dropped itself into / Applications If that is what you wanted to do, you very well could, MacPorts can generate a pkg installer of any port they have. You get the usual pick a destination, click install. >> What the method I am using does, is instal perl in /opt. Perl >> modules too. ASSP is started with a full path to perl /opt/local/bin/ >> perl assp.pl. There is no chance that ASSP is running with anything >> outside of /opt. > > An interesting idea, but I admit that I've been burned more than once > by Apple for not using their installed sw. :-/ To be honest, outside of large apple share servers, I am not sure I ever saw the value in OS X Server. The Tower is better bang for the buck, and you can use OS X client. What simply things OS X server offers, I really do not see it being needed. If you have 20 of them, the LOM is pretty nice, outside of that, software wise, client has always been the road I like most. >> I take this as far as installing all software in /opt. I don't want >> Apples rsync, so I build it in /opt. > > One of the problems I've found with the various attempts like this is > that some like /opt, some like /sw, some like .... It can get way too > messy and confusing to know what has installed what, where. You are thinking of this as a way to manage other software. I am only suggesting you use it to install ASSP. You can change the prefix to whatever you want, does not need to be /opt, though that is a pretty standard place to do so. >> MacPorts... Not a 100% mature project, but hands down the best >> package manager I have used on OS X. Hands down the most amazing >> support, they have helped me debug some of these SSL/TLS issues. > > I've used it in the past, but it was around at the time Apple support > burned me. Then Apple messed up perl for those who had updated it. > I've been burned too many times, so I have to be shy about messing > with what has worked well in the past. You keep mentioning Apple breaking perl, but keep wanting to stay in that situation. I am genuinely curious why this is? What hold on you contractually or support wise does Apple have on these xserves? I have a few, I never have talked to Apple, and a few, I am bout to put OS X client on them and be done with it. >> I barely know perl well enough to even consider this idea. But right >> now, it's far too random to troubleshoot in any meaningful way. > > assp is about as far as I want to go in CLI on my server. I have a > real life and job. Just because some who use CLI find things easy does > not mean that others want all that detail or power. Some just want a > server to do the basic things and run stably: "I want this, so, click, > I've set it on." For example, it's why Lingon is useful. I think the point to take away here, is that you should not have had to use Lingon. ASSP needs a launchd item that comes with it. It has one, it is not correct. I still need to add in the ability for MacPorts to install the launchd item, but I do have it ready. I am just not sure if I am going to blow it all away and move to 2.x of ASSP, which will change a lot. About as close as you are going to get to that is how I would install it: sudo port install assp sudo launchtl load -w /path/to/org.assp.plist Done, ASSP is running. Update comes out... sudo port update assp Want to remove it sudo port uninstall assp > Apple sells Server as a GUI-managed server. It is not, except for all > but the most basic services. Some of us have other jobs that just need > basic services for a small office and a small number of domains. > Managing the server is the least of our worries. At least, it should > be. The chasm between Apple's marketing image of the product and the > product itself is one of the largest I've seen in 25 years in the sw > business. :-/ A server is always going to require some command driven management. If you are ok with how OS X server runs out of the box, then you would not need to. Why not just use spamassassin as included with OS X? I also hear Snow will use Dovecot as the IMAP server, which should make it a quite nice machine out of the box. > Then there are all those 'open source' projects that constantly > mention Win and Linux, but seem to constantly forget OS X Unix. "Easy > install!" Not. => Frustration. In most all cases, the linux stuff runs on the Mac fine. I have been slowly adding more and more to MacPorts as I run into them. memtest was the most current one I added in. But I also had to add in 30 or so of the perl modules, and get those to all work. As long as the Linux developer made code that is POSIX compliant, in 99% of the cases, it will build clean. -- Scott * If you contact me off list replace talklists@ with scott@ * ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Assp-test mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/assp-test
