Mailman Problems under OSX Lion
This list is my last hope on getting my problems fixed.
I am running OSX Lion (not Mountain Lion). Mailman was part of the default installation.
I have two issues which I have gotten absolutely no help from Apple Enterprise Support ... basic answer, we don't support open source software and couldn't answer me on why they installed / advertised mailing lists but don't support it ... but I regress.
(1) First issue is cosmetic. At the bottom of each administrative page, mailman does not display the icons which I see on ever other mailman website ... basically the mailman / python logos. Not a real big deal, besides the cosmetic irk. I've checked the docs, found the path in the config file, and sure enough the images are there in the path, but they still do not display. Ideas?
(2) Second issue is more serious. I can't get list moderation to work. A message comes in to be moderator, I get email notification of this. However, if I login to the administrator page, "pending moderator requests", if I try to approve, reject, or any other command on that page, NOTHING happens ... the message keeps appearing, no action is taken etc.
I've repaired all permissions, but besides that, lost on what to try next.
Would appreciate any insight.
Thank you.
David Dodell
Am 13.08.2012 um 00:25 schrieb David Dodell:
This list is my last hope on getting my problems fixed.
I am running OSX Lion (not Mountain Lion). Mailman was part of the default installation.
I have two issues which I have gotten absolutely no help from Apple Enterprise Support ... basic answer, we don't support open source software and couldn't answer me on why they installed / advertised mailing lists but don't support it ... but I regress.
(1) First issue is cosmetic. At the bottom of each administrative page, mailman does not display the icons which I see on ever other mailman website ... basically the mailman / python logos. Not a real big deal, besides the cosmetic irk. I've checked the docs, found the path in the config file, and sure enough the images are there in the path, but they still do not display. Ideas?
where is apache looking for the icons. I think I read on the OS X Server List that the icons are on a different place than they should be.
(2) Second issue is more serious. I can't get list moderation to work. A message comes in to be moderator, I get email notification of this. However, if I login to the administrator page, "pending moderator requests", if I try to approve, reject, or any other command on that page, NOTHING happens ... the message keeps appearing, no action is taken etc.
anything in the logs (apache, mailman ...)?
I've repaired all permissions, but besides that, lost on what to try next.
did you try your own install of mailman as it was suggested on the os x server list?
cheers Matthias
On Sun, 2012-08-19 at 12:22 +0900, Matthias Schmidt wrote:
Am 13.08.2012 um 00:25 schrieb David Dodell:
This list is my last hope on getting my problems fixed.
I am running OSX Lion (not Mountain Lion). Mailman was part of the default installation.
I have two issues which I have gotten absolutely no help from Apple Enterprise Support ... basic answer, we don't support open source > software and couldn't answer me on why they installed / advertised > mailing lists but don't support it ... but I regress.
There are lots of mailing lists available. Mailman is only one of them. Apple no doubt supports _a_ mailing list, but as Apple Enterprise Support says, one can seldom expect support from a proprietary software vendor for software which isn't their own.
(1) First issue is cosmetic. At the bottom of each administrative page, mailman does not display the icons which I see on ever other > mailman website ... basically the mailman / python logos. Not a > real big deal, besides the cosmetic irk. I've checked the docs, > found the path in the config file, and sure enough the images are > there in the path, but they still do not display. Ideas?
where is apache looking for the icons. I think I read on the OS X Server List that the icons are on a different place than they should be.
Look in your apache error log. If a page is trying to display a graphic, another page, or any file that's linked from a served page, and apache can't find it, it'll log the error.
(2) Second issue is more serious. I can't get list moderation to work. A message comes in to be moderator, I get email notification of this. However, if I login to the administrator page, "pending moderator requests", if I try to approve, reject, or any other command on that page, NOTHING happens ... the message keeps appearing, no action is taken etc.
anything in the logs (apache, mailman ...)?
The vast majority of problems on any Unix type system leave footprints in logs at a system level. These are definitely your first recourse in any investigation. Logs in Unix-type OSes (OS X, Linux, BSD, etc.) are almost invariably in /var/log, and are one of the things I really love about Unix-flavor systems :)
I've repaired all permissions, but besides that, lost on what to try next.
did you try your own install of mailman as it was suggested on the os x server list?
I've very frequently had the best luck installing Mailman (and other software packages) from a tarball and _slavishly_ following the install directions. My policy on such installs out of the chute is: do not deviate, do not pass Go, do not collect even a singly byte of what you perceive as slack! If the install screws up and some part of it won't work, you have a clear path back from which others on forums such as this one can follow your tracks, plus if there's a genuine bug, you can report it as same without concern that it might be the result of some step you skipped, or added, or some non-standard procedure that you followed. If one does a totally politically correct install, and still has problems, then it's time for some sleuthing and experimentation.
--
Lindsay Haisley | "Never expect the people who caused a problem
FMP Computer Services | to solve it." - Albert Einstein
512-259-1190 |
http://www.fmp.com |
On Aug 19, 2012, at 8:11 PM, Lindsay Haisley <fmouse-mailman@fmp.com> wrote:
There are lots of mailing lists available. Mailman is only one of them. Apple no doubt supports _a_ mailing list, but as Apple Enterprise Support says, one can seldom expect support from a proprietary software vendor for software which isn't their own.
This has long been a major bone of contention. We're happy to have them take our software, but if they're going to make modifications to it, they need to share those modifications back with us -- and support their mods. If they're going to ship a modified version of our software but then not provide those modifications back to us and not support their modifications, and not provide any support for what they have shipped? Well, then that makes them the bad guys -- they don't give us any way to be able to provide support to their customers, and they don't support their customers themselves. Regretfully, the Server team at Apple is well known for ignoring feedback and input from anyone else, especially anyone else in the company.
But as I said, this is an old bone of contention.
-- Brad Knowles <brad@shub-internet.org> LinkedIn Profile: <http://tinyurl.com/y8kpxu>
Am 20.08.2012 um 12:33 schrieb Brad Knowles:
On Aug 19, 2012, at 8:11 PM, Lindsay Haisley <fmouse-mailman@fmp.com> wrote:
There are lots of mailing lists available. Mailman is only one of them. Apple no doubt supports _a_ mailing list, but as Apple Enterprise Support says, one can seldom expect support from a proprietary software vendor for software which isn't their own.
This has long been a major bone of contention. We're happy to have them take our software, but if they're going to make modifications to it, they need to share those modifications back with us -- and support their mods. If they're going to ship a modified version of our software but then not provide those modifications back to us and not support their modifications, and not provide any support for what they have shipped? Well, then that makes them the bad guys -- they don't give us any way to be able to provide support to their customers, and they don't support their customers themselves. Regretfully, the Server team at Apple is well known for ignoring feedback and input from anyone else, especially anyone else in the company.
that's partly also true for postfix. The mods Apple made are undocumented and not reported back to the postfix developers. This concerns basically the OpenDirectory integration.
Besides that, Apple is not shipping mailman anymore with MoutainLion Server, so people are already installing it separately and that's what I would do under Lion as well.
What makes me wonder is that the OP has an AppleSupport contract and mailman is shipping with Lion, I find that more than strange ...
cheers Matthias
On Sun, 2012-08-19 at 22:33 -0500, Brad Knowles wrote:
Regretfully, the Server team at Apple is well known for ignoring feedback and input from anyone else, especially anyone else in the company.
My guess is that they don't put their top-flight people on either server development or server support. Apple isn't know for servers, it's niche markets being audio recording, graphics editing and consumer desktop and laptop systems. I've also observed, with somewhat limited experience, that Apple doesn't respond to complaints about bugs. People bitched and moaned on Apple's user forum about a recent problem with video-induced kernel panics in Lion (which I also experienced) and Apple never responded, but the problem was fixed in a subsequent release.
but if they're going to make modifications to it, they need to share those modifications back with us
Doesn't their failure to do so violate the GPL?
-- Lindsay Haisley | "Real programmers use butterflies" FMP Computer Services | 512-259-1190 | - xkcd http://www.fmp.com |
Lindsay Haisley writes:
but if they're going to make modifications to it, they need to share those modifications back with us
Doesn't their failure to do so violate the GPL?
No. The GPL requires that you grant certain rights to use of your code to downstream recipients, not that you publish code or give it back to upstream developers.
It's failure to provide source code to paying customers (even if the price was zero) that violates the GPL. If one of us is willing to buy a server system and demand source code, they either cough up or they suffer a rerun of the Objective-C embarrassment, and then they either cough up anyway or they lose the right to distribute Mailman.
Alternatively, if somebody knows somebody with a server system who's willing to piss off Apple, the first somebody could get the second somebody to do it.
This has been done in other contexts (the cPanel Mailman patch was outed at least once by a customer, and maybe Plesk's, too), but the history with Apple seems to go like this:
- Bug bites Mac server system's Mailman.
- Victim wastes time talking to Apple. By the time they realize it is a waste of time, they're panicking.
- Willing to do anything, they come here and are advised to install Mailman from source as described in our INSTALL file. (This advice was especially effective when coming from Chuq. :-)
- Victim discovers there's nothing they want from the Apple version, and by the time they've put out all the other little fires that sprang up while they were fighting the Mailman fire, they cool off enough to realize there's nothing to benefit *anybody* in the Apple version, and it would be best if it just went away, so they don't bother asking for code. ;-)
Steve
On Aug 20, 2012, at 12:18 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
It's failure to provide source code to paying customers (even if the price was zero) that violates the GPL. If one of us is willing to buy a server system and demand source code, they either cough up or they suffer a rerun of the Objective-C embarrassment, and then they either cough up anyway or they lose the right to distribute Mailman.
Alternatively, if somebody knows somebody with a server system who's willing to piss off Apple, the first somebody could get the second somebody to do it.
I've got a copy of Mountain Lion server (it's only $20), and the code in question is Python, so it has to be shipped as source. So, if we want their changes, it's easy enough to get them.
For me, the point is more than they don't actively contribute their changes back to the project, and actively support those changes. If they actively contributed their changes back and actively supported their changes, then we could easily adapt the mainstream version of Mailman so that it would install and build in exactly the same locations with exactly the same localized changes for the platform, and then it should be trivial for people to upgrade.
More importantly, it would be much less difficult for us to support that part of the community, which would help reduce the support burden that Apple has to maintain.
With Xcode switching from llvm from gcc for the backend, and the way that llvm is continuing to be developed in partnership, maybe we can convince them to take a similar approach to Mailman and other open source software?
This has been done in other contexts (the cPanel Mailman patch was outed at least once by a customer, and maybe Plesk's, too), but the history with Apple seems to go like this:
- Bug bites Mac server system's Mailman.
- Victim wastes time talking to Apple. By the time they realize it is a waste of time, they're panicking.
- Willing to do anything, they come here and are advised to install Mailman from source as described in our INSTALL file. (This advice was especially effective when coming from Chuq. :-)
Yes, well -- he had the advantage that not only was he an Apple employee, he was also running lists.apple.com, and used Mailman to do it. Other people working at Apple would not have nearly the same level of impact.
- Victim discovers there's nothing they want from the Apple version, and by the time they've put out all the other little fires that sprang up while they were fighting the Mailman fire, they cool off enough to realize there's nothing to benefit *anybody* in the Apple version, and it would be best if it just went away, so they don't bother asking for code. ;-)
That sequence of events doesn't serve anyone well -- not the customer, nor Apple, nor our community. We can do better.
-- Brad Knowles <brad@shub-internet.org> LinkedIn Profile: <http://tinyurl.com/y8kpxu>
On Aug 20, 2012, at 1:18 PM, Brad Knowles <brad@shub-internet.org> wrote:
With Xcode switching from llvm from gcc for the backend, and the way that llvm is continuing to be developed in partnership, maybe we can convince them to take a similar approach to Mailman and other open source software?
s/from llvm/to llvm/
-- Brad Knowles <brad@shub-internet.org> LinkedIn Profile: <http://tinyurl.com/y8kpxu>
On Mon, 20 Aug 2012, Brad Knowles wrote:
I've got a copy of Mountain Lion server (it's only $20), and the code in question is Python, so it has to be shipped as source. So, if we want their changes, it's easy enough to get them.
Actually, it doesn't have to be shipped as source. They could ship just the .pyc files.
But this doesn't mean it's not shipped as source. Anyone with Apple Server could confirm this one way or the other.
Geoff.
On Mon, 2012-08-20 at 21:39 +0300, Geoff Shang wrote:
On Mon, 20 Aug 2012, Brad Knowles wrote:
I've got a copy of Mountain Lion server (it's only $20), and the code in question is Python, so it has to be shipped as source. So, if we want their changes, it's easy enough to get them.
Actually, it doesn't have to be shipped as source. They could ship just the .pyc files.
The GPL only requires that the source be "made available", yes? So functionally the .pyc files would be adequate for all but a few files such as Defaults.py, with the full .py source withheld pending a specific request for it, as prescribed by the GPL. Doing this would minimize redundancy and would make sense, from the point of view of a proprietary software vendor such as Apple.
-- Lindsay Haisley | "The difference between a duck is because FMP Computer Services | one leg is both the same" 512-259-1190 | - Anonymous http://www.fmp.com |
Brad Knowles writes:
More importantly, it would be much less difficult for us to support that part of the community, which would help reduce the support burden that Apple has to maintain.
C'mon, Brad, it's *annoying* to have to support that part of the community, but it's never been difficult. "Install Mailman from source, OK?"
With Xcode switching from llvm from gcc for the backend, and the way that llvm is continuing to be developed in partnership, maybe we can convince them to take a similar approach to Mailman and other open source software?
llvm is a key component of their strategy for Mac OS X developer support as far as I can see. They did the same with CUPS for users. But I don't think Mailman is a big part of their overall strategy. They just considered it a cool thing to put in their distribution.
(This advice was especially effective when coming from Chuq. :-)
Yes, well -- he had the advantage that not only was he an Apple employee, he was also running lists.apple.com, and used Mailman to do it.
Well, the real point is that as somebody running some of the biggest most active lists in the world, he didn't use Apple's version -- he used and advocated stock Mailman. And he didn't have a lot nice to say about Apple server support, either.
That sequence of events doesn't serve anyone well -- not the customer, nor Apple, nor our community. We can do better.
*We* can. Apple won't.
Now, if somebody here can channel Steve Jobs and get direct access to the top execs at Apple, maybe they could force the server people to turn over maintenance to us. But the server division would surely fight that with fire.
On Aug 20, 2012, at 10:56 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
More importantly, it would be much less difficult for us to support that part of the community, which would help reduce the support burden that Apple has to maintain.
C'mon, Brad, it's *annoying* to have to support that part of the community, but it's never been difficult. "Install Mailman from source, OK?"
That's not difficult for the likes of you or me, but I can guarantee you that doing something like installing Mailman from source is very difficult for the average OS X admin.
If Apple did their part, then we could do our part to make the upgrade process relatively simple and painless, even by OS X standards -- i.e., drag-n-drop and you're done.
llvm is a key component of their strategy for Mac OS X developer support as far as I can see. They did the same with CUPS for users. But I don't think Mailman is a big part of their overall strategy. They just considered it a cool thing to put in their distribution.
I think Mailman was a bigger part of their overall strategy prior to Mountain Lion, but if the reports are to be believed then they eliminated the install of Mailman at the same time as they eliminated the ability to easily run a web server based on the apache2 code that is still installed.
Sure, if you find the right articles on the right MacFanatic websites, you can be lead to a PrefPane that you can add to your system that will allow you to re-enable apache2, but that doesn't change the fact that apache is disabled by default and there is no standard OS-provided way to turn it back on.
Been there, already done that.
I think Apple is in the process of removing a lot of stuff from the Server component. As to what motivation you want to ascribe those actions to, well that's your choice.
Yes, well -- he had the advantage that not only was he an Apple employee, he was also running lists.apple.com, and used Mailman to do it.
Well, the real point is that as somebody running some of the biggest most active lists in the world, he didn't use Apple's version -- he used and advocated stock Mailman. And he didn't have a lot nice to say about Apple server support, either.
My point was more about the fact that he said the things he did, but specifically as the guy who was running lists.apple.com.
No other person who works (or worked) at Apple and said the same sorts of things would be likely to carry the same kind of weight. And no one outside of Apple would be able to say the same kinds of things and have them carry the same kind of weight with people who are using OS X Server.
The key is not just what he was saying, which I was taking as granted. The key is that he was saying those things as a person uniquely positioned to be able to say them and have them carry weight with the particular user community in question.
*We* can. Apple won't.
As I said, we can do better.
Now, if somebody here can channel Steve Jobs and get direct access to the top execs at Apple, maybe they could force the server people to turn over maintenance to us. But the server division would surely fight that with fire.
At their worst, they would not have fought the effort with fire. They would have simply ignored it, and it would never have happened.
However, I am starting to wonder if this kind of stuff going away is not part of an overall effort to dumb-down OS X so that it can be unified with iOS.
I do recall some slips at the WWDC Keynote address where it was referred to as "iOS X" by a couple of people.... At least, it does make me wonder how something like Mailman could be re-written to work effectively on something like iOS.
-- Brad Knowles <brad@shub-internet.org> LinkedIn Profile: <http://tinyurl.com/y8kpxu>
Brad Knowles writes:
However, I am starting to wonder if this kind of stuff going away is not part of an overall effort to dumb-down OS X so that it can be unified with iOS.
Could be, but in that case I would expect that their strategy is to completely eliminate server support, and try to get MacUsers to use iCloud to provide all server services.
And they can use all the GPLed code they want in the iCloud, and noone need ever even know....
I do recall some slips at the WWDC Keynote address where it was referred to as "iOS X" by a couple of people.... At least, it does make me wonder how something like Mailman could be re-written to work effectively on something like iOS.
Mailman would be fine, if they'd allow us to port Python to iOS. The problem would be the MTA.
On Aug 20, 2012, at 9:00 AM, Lindsay Haisley <fmouse-mailman@fmp.com> wrote:
My guess is that they don't put their top-flight people on either server development or server support.
I believe that they do have high quality people working on the development side, I think the issue is more on the support side. And the fact that they don't want to talk to *ANYONE* outside of the server team itself.
Apple isn't know for servers, it's nichemarkets being audio recording, graphics editing and consumer desktop and laptop systems.
The irony is that they've done quite well on the server side, in the SOHO and workgroup business market. Since Snow Leopard, the server version has been much cheaper than Windows server solutions, and they don't put any limits on how many machines you can use your licensed copy of the software -- which is why I always made sure to buy the group or family license (authorized for up to five machines), even though I was only using it one two or three machines in the house.
Apple's problems have historically been with the Enterprise market, as opposed to SOHO and workgroups.
I've also observed, with somewhat limited experience,that Apple doesn't respond to complaints about bugs. People bitched and moaned on Apple's user forum about a recent problem with video-induced kernel panics in Lion (which I also experienced) and Apple never responded, but the problem was fixed in a subsequent release.
Apple does listen to complaints and usually does respond, in different ways to different types of complaints -- also depending on how loudly people are complaining and how many of them there are. Fixing a problem in the next release is one way they respond, another way is holding an impromptu press conference to explain why "Antennagate" is much ado about very little.
However, Apple frequently does not respond in the way that most people would expect or want them to. I think a simple acknowledgement that there is a problem would go a long ways towards defusing a lot of the issues that have happened in the past.
but if they're going to make modifications to it, they need to share those modifications back with us
Doesn't their failure to do so violate the GPL?
In this respect, I believe that they are probably in violation of the spirit of the GPL, but perhaps not in the letter of the law. Which is probably why they are so very violently opposed to having any GPL-encumbered code anywhere in the company.
-- Brad Knowles <brad@shub-internet.org> LinkedIn Profile: <http://tinyurl.com/y8kpxu>
Brad Knowles writes:
Doesn't their failure to do so violate the GPL?
In this respect, I believe that they are probably in violation of the spirit of the GPL, but perhaps not in the letter of the law.
RMS is adamantly opposed to that interpretation of the "spirit of the GPL," and has said so on many occasions. Usually in the context of refusing to certify a license as a "free software license" because it contains some kind of give-back clause. Free software licenses are allowed to contain only give-forward clauses.
Which is probably why they are so very violently opposed to having any GPL-encumbered code anywhere in the company.
GCC? gdb? binutils? Make? CUPS? Mailman? And that's just the applications I know of in the Mac OS X distribution itself; I'm sure there are plenty of developers who use Emacs and other GNU tools in preference to the Mac-supplied tools at Apple.
That said, yes, Apple clearly avoids the GPL. I think it's at least in part a reaction to the Objective-C fiasco, but mostly a pragmatic balance between the cost and quality benefits of using a lot of open source and Apple's general strategy of exploiting intellectual property in creative ways to make profits. Including other folks' IP (iTunes, for example, would be a much smaller deal if Napster hadn't been crushed).
Steve
On Aug 20, 2012, at 9:03 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
Which is probably why they are so very violently opposed to having any GPL-encumbered code anywhere in the company.
GCC? gdb? binutils? Make? CUPS? Mailman? And that's just the applications I know of in the Mac OS X distribution itself; I'm sure there are plenty of developers who use Emacs and other GNU tools in preference to the Mac-supplied tools at Apple.
Gcc & gdb are gone -- replaced by llvm. I believe that CUPS is also gone, but I may be wrong.
And if another commenter on this thread is correct (I have not yet checked the Mountain Lion Server image that I have), then Mailman is also gone.
And I can most definitely confirm that Apple is actively eliminating any use of GPL-based technologies or tools within the company.
They even eliminated X out-of-the-box, although you can still download it from an alternative site. Of course, you could claim that was a disk space issue, but then they're no longer shipping the OS on physical media.
-- Brad Knowles <brad@shub-internet.org> LinkedIn Profile: <http://tinyurl.com/y8kpxu>
Brad Knowles writes:
On Aug 20, 2012, at 9:03 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
Which is probably why they are so very violently opposed to having any GPL-encumbered code anywhere in the company.
GCC? gdb? binutils? Make? CUPS? Mailman?
Gcc & gdb are gone -- replaced by llvm.
Sure, and I can see why they'd want to do that. My point is simply that Apple is pragmatic about it. Sure, they want permissive licenses if they can get them, and I think the FLOSS world is heading in that direction. I'm not surprised they take advantage of the trend.
They even eliminated X out-of-the-box,
X11 is still a mess, and their development philosophy still sucks for users and 3rd-party developers. If I can use the Mac GUI, I do. Again, de-supporting X is arguably a pragmatic decision.
David Dodell wrote:
(1) First issue is cosmetic. At the bottom of each administrative page, mailman does not display the icons which I see on ever other mailman website ... basically the mailman / python logos. Not a real big deal, besides the cosmetic irk. I've checked the docs, found the path in the config file, and sure enough the images are there in the path, but they still do not display. Ideas?
Look in mm_cfg.py and Defaults.py for the definition of IMAGE_LOGOS. Our default setting is
IMAGE_LOGOS = '/icons/'
which says the logo images should be displayed and will be found at URLs like http://<url_host>/icons/<logo_file>. If there is something like
IMAGE_LOGOS = 0
in mm_cfg.py, this is what says don't use the logos.
Look at the source of the page to see if there is an img tag for each logo. If not, IMAGE_LOGOS has a False value. If so, you can adjust IMAGE_LOGOS to generate a correct src= URL, or just make sure the files are copied to the web server's /icons/ directory.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (8)
-
Brad Knowles -
David Dodell -
Geoff Shang -
Lindsay Haisley -
Lindsay Haisley -
Mark Sapiro -
Matthias Schmidt -
Stephen J. Turnbull