GroupServer Installation Troubleshooting
Summary
- There are 14 posts — by 6 authors — in this topic.
-
Posts with files From File Date Michael JasonSmith Nov 14 01:35 UTC - Latest post made by David Sturman at Nov 15 03:07 UTC
I wanted to share some things I learned in the process of being helped through installing GroupServer. I could not have done it without help and now I want to share what worked so that others might also have an easier time getting a successful install. There are some things in the GroupServer Install Guide http://www.groupserver.org/downloads/install that just did not work for me. I am running a stock new install of Ubuntu 11.04 (Natty) with updates applied, nothing fancy. It is not installed on a local system with a GUI and browser, so I must interact remotely -- as is very common in what is intended to become a production machine. Rather than duplicate all the install steps, I'll just share some things I did that are in addition or inspite of the existing guide. If Devel wants to update install guide/docs, I encourage them to do so. Here are some suggested modifications for the install page content or related documentation: Quick Start - 3. Create a new user to run Groupserver. Assure the user can create databases in PostgreSQL. Create and test users/e-mail addresses for admin_email and user_email entries. Configure PostgreSQL - change "$ sudo service postgresql-8.4 restart" to "$ sudo service postgresql restart" [I'm not sure where the below details would be added] Create a user and group to run groupserver. Even if one does not specifically tell the installer how to do this, it is an important step to a successful installation. I would recommend installing GS in the created user's home directory. One example would be user: groupserver, group: groupserver with home as /home/groupserver. As new versions come out, they will all be in this home directory. Create and test additional users to satisfy the admin@, user@, and support@ requirements. For a successful Groupserver installation, working e-mail addresses must be specified in instance.cfg (see Configuring Zope). 4.1 Pick a Host Name -- changes to correct typo and clarify: Your new site needs its own hostname. The name needs to be known to the web browser that you will use to access the site. It will pass the name to Zope so it knows which GroupServer site to serve. (Zope can serve multiple sites, as well as its web-based management system.) For a production site, you will need to configure the hostname in your DNS in addition to the hosts file. • Add the new host name to the external/public IP. For example, to add the name gstest, add the following to your external/public IP: XXX.XXX.XXX.XXX gstest.yourdomain.nam gstest [I'd like to add that this single step is the only one that directly contradicts what is stated in the install guide, and it is critical to getting the install to work on a remote system. Thanks to Richard Waid for helping to get this detail sorted out.] 4.2.1 Groupserver Host The domain name used by your new GroupServer instance. It must be entered as the fully qualified name (example: gstest.yourdomain.nam) that matches what you picked as a host name earlier (see Pick a Host Name). admin_email When GroupServer is installed, an example site and group are created. So you can use the administration functions you must log in as an administrator. This is the email address of that administrator. Posts to the example group will be sent to the administrator at this address. In addition, this email address will be used to log into the new site. Note: GroupServer will not setup the example site or group successfully unless this address is setup and working when you first start Zope or installation will not be successful. user_email The email address of the normal user that is created along with the new GroupServer site. The normal user is a member of the same group as the administrator, but the user has no permission to alter the site. Posts to the example group will be sent to the user at this address. In addition, this email address will be used to log in to the new site. The email address for the normal user must be different from the email address for the administrator. Note: GroupServer will not setup the example site or group successfully unless this address is setup and working when you first start Zope or installation will not be successful. 4.2.2 SMTP GroupServer sends email using SMTP. The four smtp options contain the information required to comminicate with the SMTP server. Note: SMTP must be configured and working for the admin_email and user_email when you first start Zope, or installation will not be successful. 4.2.3 Zope zope_host The host that will run Zope. It must be entered as the fully qualified name (example: gstest.yourdomain.nam) It defaults to the local machine. After the install, as user groupserver, I change to the groupserver install directory /home/groupserver/groupserver-11.08: start with ./bin/instance start stop with ./bin/instance stop I can also run it in the foreground with debug with the command as listed in the install guide: ./bin/instance fg Foreground and debug are helpful for determining if there are issues but it does not seem the best approach for a production server... it would also be helpful to advise instance fg users that they may terminate the foreground instance by pressing ctrl + c. I'm still planning to do a final ground up installation before production, so I will update/share every step once I get through that point.
Hi Ross, Thank you so much for your corrections to the installation documentation. I have made some changes: * I fixed the command that is used to restart PostgreSQL. * I corrected my typing error in the Pick a Host Name section. * I added a new section for how to run Zope as a daemon. You can see the updated installation documentation at <http://groupserver.org/downloads/install/>. ❧ Most of your other corrections are excellent. However, I do not think that GroupServer is ready for them. Currently the installation documentation is written for someone who wants to give GroupServer a try; I deliberately did not write the documentation for someone who wants to set up a production system. There reason for this is two fold. First, while GroupServer itself can handle production systems fine, the installation code is not that good. Once the installation system works more smoothly I think we can start to look at making the installation documentation better for production systems. The second reason that production systems are not covered is that I am not an administrator, so I would struggle to set up a production system that I would require to write and test the documentation. With that in mind, my specific comments are below. You are right that best practice is to set up a new user to run GroupServer. However, for just giving GroupServer a go this is an unnecessary step. Ideally GroupServer would be packaged up by a distribution that would create a user for GroupServer as part of the installation process. Specifying an external IP address is too complex for just giving GroupServer a try, and providing instructions for both local and external IP addresses would increase the complexity of the installation documentation further. I have a different issue with saying that the "admin_email" and "user_email" addresses should work. It *implies* that the other parts of the installation documentation are optional. They are not: you need a working PostgreSQL configuration, you need a working host-name, and you need a working SMTP server. A better course of action would be for the system to check that PosgreSQL, the host, email addresses, and SMTP configuration works at the very start of the buildout process. That way better feedback can be given if anything goes wrong.
My apologies if my reply is received as offensive, too long, and overly enthusiastic in supporting my positions. Perhaps we should not use the word "should". Let's say the admin_email and user_email MUST work for installing GroupServer. I say this because when you get to the point where you see the ZMI and cannot see the initial site because "Zope has encountered a problem publishing your object. Cannot locate object at: http://localhost:8080/example/@@index.html"). There is no explanation of why this is happening -- such as "Unable to create example site, unable to create example group, unable to notify or add admin_user and user_e-mail members. Zope is not even close to being obvious or helpful about what is wrong. Perhaps you'll find this helpful post as it is in your own words: http://groupserver.org/r/post/6paGFxFBbmp41tanml8zGi "Without an SMTP connection GroupServer cannot send notifications. Without notifications GroupServer is unable join anyone to a group. Without the ability to join people to groups GroupServer cannot set up the example group. Without the example group GroupServer cannot create the example site. Without the example site none of the web pages will work." It is clear you know the admin_email and user_email are needed before running ./bin/instance fg to start Zope and do all those steps that you say cannot be done without those notifications going to those e-mail addresses. You say the SMTP server needs to be working and it does, but it is also necessary to have the e-mail addresses working. My experience proves what you said in the post referenced above. I did not suggest that other elements in the configuration are not important. When you fail to say (anywhere in the install guide) that the e-mail addresses that we configure in instance.cfg must be created and working when we do the install or it will not work, I think it is important to emphasize that the addresses must be working. How you choose to add the emphasis in the install guide is up to you but it had better be sometime before you run ./bin/instance fg for the first time because GroupServer must send notifications to the admin_email and user_email addresses in order to join them to the group, setup the example group, and create the example site. Without that, none of the site web pages work and you get the Zopist error message shared above -- all because two e-mail addresses can't get a notification! Buildout can finished before the e-mail addresses are created and verified as working... but i would rely on the install guide being written in a linear format from start to finish (step-by-step). I don't find that it does that as well as it could. The time to realize the admin_email and user_email need to be "real, working, valid" is before one gets too far. Once Postfix is installed, it makes perfect sense to create the e-mail addresses and test them -- this assures Postfix (SMTP) is working as it should -- and as you say it needs to be working. I think it makes more sense to assure when editing instance.cfg, that we know the e-mails are created and working to receive e-mail notifications. When we run ./bin/instance fg, all the site/group/member/notification stuff happens (or fails in a way that is not clear or obvious). I do not understand the logic of intentionally leaving important information out of the install guide with the idea that it is an enhancement to evaluation. The purpose of advertising GroupServer as a working solution to compare against Mailman or GoogleGroups *production* solutions is to encourage people to install GroupServer in production. Do you want to say GroupServer is not ready for production? If it isn't, please call it test/beta software and say NOT FOR PRODUCTION USE. I am disappointed if the idea of deliberately hobbling the installation guide is keen for evaluation! As I understand it, GroupServer is presently supporting millions of messages a month with many tens of thousands of subscriber/members -- I call that a production-ready solution! Naturally, install could be made easier, features could be put into the web interface instead of being configured manually through the ZMI. I understand Devel has higher priorities and limited resources for the public software. I also know evolution will eventually come. The important aspect now is to support and grow the audience and encourage more people to get involved and lend support. This will happen most effectively when it is considered in production and does what real users need it to do. I can live with a few warts and hiccups and extra steps during or after install as long as what is written for me to follow works. I don't want to see us wait for GroupServer 15.3 (Dango consumed in Japanese Garden while composing Haiku) to discover all it has waiting to offer, just so it can install perfectly simple, easy. The present installation guide is a deterrent to evaluation and production because it assumes things it does not state, and says things that directly contradict the required configuration to make it work on a remote or production system. Consistency is very important and making assumptions is very bad. The install guide does not state that it is for evaluation only and it does not say that it is for installing on a local system with a GUI and web browser on the same local system. Localhost 127.0.0.1 recommendation would only work in that very limited scenario, but it must absolutely not be setup that way for any other scenario. This is critically important and something the installation guide does not mention at all! Even that notice would be sufficient for a serious installer to stop and think, then wonder why there isn't any install guide for other scenarios such as remote systems or a production server. The installation instructions drive people away from GroupServer if things do not fit your imagined/assumed configuration. The time spent not getting anything to work becomes a frustrating failure. If people come to the GroupServer website looking for help, it is likely you will share (that you are not an administrator and cannot help, test, or verify the configurations needed to get GroupServer installed and working). How long before people read this and conclude the software isn't ready and support is just not serious about making it work for the public? I once thought the approach was intentional as an effort to drive people to pay for the services of your company -- such as a paid install. I inquired but get the impression that everyone is busy enough as-is with your servers, development efforts on the public software, and having personal lives. I like that it suggests you are not all living in a dungeon and fueled up on energy drinks and snack foods. It is good to have a desire for a quality in life and work balance. I first "evaluated" GroupServer back in July 2011. I had issues and could not get the install to work so I could see anything in a web browser. No ZMI, no site, no pages -- just errors. I was unable to evaluate GroupServer. At the time, support told me I needed to have more admin experience configuring Apache2 and that help for that wasn't available. It was frustrating and my evaluation soon stalled out. I asked a colleague with years of Linux admin experience to attempt his own installation of GroupServer -- he did not have success and he followed the install instructions exactly as written. There was a point in our mutual frustration over GroupServer install that we called it a dead cat (no offense to dead cats). I am glad I did not leave it there as what I see now completely eliminates the install frustrations and shows why GroupServer has the potential to be the best solution available. I suggest you take a different approach when writing an installation guide. The goal should be to make the installation as detailed as necessary to be successful to the widest potential audience. If you are able to simplify the installation by scripting to address some of the issues, that's great. When things are wrong and the script discovers them, you still need to tell the user what has to be done to fix them, and I think there is no reason not to have that information available in the install guide to make things work -- and having it in the install guide will educate the installer at the same time. To address the two main points you support for the deliberate drafting of an install guide that does not work for remote/Lan/production... 1. I mentioned to others in Devel at GroupServer.org, that your group should have a means to test the installation documentation and downloaded file to assure they work as they should. Open source Oracle Virtual Box would enable you to install the OS, required packages, and GroupServer on any pc running a host OS from Windows, Linux, Mac. You would then have the admin opportunity you say you do not have now. You might also consider getting an older spare PC and using it for a "lab" environment. From my point of view, the fact that you are not an administrator excludes you from many things -- I applaud your honesty to admit not having the admin opportunity, but it begs the question "why are you not an admin, or unable to create an environment where you can be one?". When one finds a deficiency, they should strive to improve upon it rather than use it as an excuse. The amount of admin skills needed for installing GroupServer and the required components is not that great. The important aspect is to gain the detailed information necessary to know what has to be done to make GroupServer work. I am very disappointed to think that all the useful information was deliberately left out because you think it would deter an evaluator -- and that admins who want to install for production are such wussies that they will hold off until you make the install script so easy that a kiddie could use it, meanwhile you tell them "go fish!" 2. When I initially asked about GroupServer installation issues, I was reminded that the installation documentation was written for someone who had sufficient administrative skills to install and configure Apache2, Postfix, PostgreSQL, create users/groups, set permissions, and do other admin tasks. What person is going to evaluate GroupServer with the current installation instructions and not have the administrative skills and experience to follow a "Step-by-Step" detailed guide on what has to be done and why? If one lacks the admin skills or wants the simplest possible evaluation, sign up for the online hosted solution and see all you need to see. I think most people who follow the existing installation instructions may have a desire to put it into production or at least have all the information needed to do so. When things fail (because you do not provide enough information) they'll decide that GroupServer isn't worth their time. Until reading it was intentionally limited, I thought the install guide wasn't detailed enough because you didn't know the details or have experience doing a full install from OS to requirements to full GS install. Now, it seems you do know more but desire to limit success outside the narrow confines of your assumed local installation with a GUI and web browser FOR EVALUATION PURPOSES ONLY. I don't think anyone would be impressed by learning they have to wait for a smoother installation before they can put it into production. I like the idea of making things *simpler* and easier but admins seeking to install for production are focused on getting the information needed to get a working system - a bit more work and information isn't going to deter them. I peppered dozens of e-mails to Devel so we could figure out what had to be done to make the GroupServer installation successful on a remote system (production or otherwise). My thought is to share ALL that information so that people are able to put it to use and get an installation that succeeds. I think it is a better use of Devel's time to devote it to the product rather than address the same issues and questions over and over. As an installer, I don't care whether the install is difficult or the guide is three or 13 pages in length. I care about quality and details I need. As long as it is written well, has all the details, and is logically thought out, the results are assured -- I want the results to be successful. I have installed Plone 4, Mailman with Postfix and Apache2, and a good number of other solutions in the evaluation process to find the best solution for a blended e-mail and web solution. GroupServer has the best potential as it looks good on paper and when running on the two sites your company maintains. The documentation is lacking, and I think it has to do with mindset of writing to suggest install is easy or writing to suggest evaluating only in a limited install. That kind of thing drives serious people away unless they are very persistent. An example of a complex installation: visit www.sympa.org and take a look at the hundreds of pages of their install/configure manual. Whether you make/install and then spend hours trying to configure it while the manual jumps around from section to section out of order, or install a bug ridden older distro using "apt-get install sympa", you will find it does not work without tedious configurations and trial and error. The support for that product pales in comparison with GroupServer.org! I have yet to see Sympa work and gave up on it completely. I installed Mailman with Postfix and Apache2 and it all works nicely, but it is lacking in web interface, database, and many other aspects -- all things GroupServer seeems able to do nicely -- especially once the procedures are documented for making changes in ZMI or they are available in the web interface. GroupServer installation is a walk in the park with the extra details from the notes I shared on what actually works. I believe more people are likely to try GroupServer with the details in the install guide to make the install work properly on a wider array of systems -- and educate the installer about what is needed and why. If a person follows what has been shared they will be able to access the ZMI and the initial site, create groups, add users, etc. If you install GroupServer without a user being created to run it, it is very likely it will be installed as root and there are known problems if/when GroupServer is installed as root. Zope is not happy with that scenario either. I'm still confused as to why you think it is so difficult for an evaluator to create a user, setup two accounts for the email addresses and install the solution properly, choosing localhost for a local install with GUI and web browser or choosing to configure hostname on external IP. We still lack some details for production, but I am still creating posts, asking more questions, learning more from reading posts, etc. If you note my suggestion, it is very simple to tell the user IF they are installing for evaluation locally, then they should add the hostname to the localhost 127.0.0.1 and IF they are installing for a remote server, lan or production, it must be added to the external/LAN IP address. If you cannot configure an IP address then you are not an administrator! You'll get no argument from me in desiring to make the install process smoother, simpler and even to add checks for various elements in the configuration. Please don't hold up accurate information or details that prevent installing GroupServer on a remote machine or LAN. Approach all install guides with the intention to do it as it would be done in production. There was earlier talk about a virtualized GroupServer evaluation -- I think I could create one if there is sufficient interest. I would not consider it unless it assures there is more focus on an install guide for those who want to install GS and put it to use.
Perhaps we could compromise and have an extended version of the documentation, at least until the automated checks are written? We already have a quickstart set of instructions along with the standard version. However, rather than us writing automated checks in scripts, I'm wondering if something like Chef[1] or Puppet[2], with their infrastructure-as-code approaches, might be a better solution. [1] http://wiki.opscode.com/display/chef/Home [2] http://puppetlabs.com/
And why not have rough drafting space on a wiki or even a Google Doc so these details get documented in a single location as well by those who figure them to spread out the work load. Steven Clift <email obscured> - +1 612 234 7072 http://stevenclift.com - @democracy
On Oct 26, 2011 2:30 AM, "Murphy, Alice" <email obscured>> wrote: > Perhaps we could compromise and have an extended version of the > documentation, at least until the automated checks are written? We already > have a quickstart set of instructions along with the standard version. > > However, rather than us writing automated checks in scripts, I'm wondering > if something like Chef[1] or Puppet[2], with their infrastructure-as-code > approaches, might be a better solution. > > [1] http://wiki.opscode.com/display/chef/Home > [2] http://puppetlabs.com/ > ----------------------------------------- > Full text of this topic in GroupServer Development: > http://groupserver.org/r/topic/7ccjDXcgYgptRgB8Y86wru > > To leave GroupServer Development, email > <email obscured>?Subject=unsubscribe > > Start your own free groups and site with > OnlineGroups.Net http://onlinegroups.net > > Host your own online groups site with > GroupServer http://groupserver.org >
I've documented my process for getting GroupServer up and running from scratch on an Amazon EC2 instance. I was going to send it to the group, but then got sidetracked by other things. It's for GroupServer 11.05. If there were a good place to put it, I'd be happy to do so. EC2 is pretty good. For about US $70/month (first year free), I get a clean machine over which I have complete control. Our GroupServer is used by a lot of people for our beta testing groups, so I'm hesitant to upgrade it since there isn't anything so broken that it's worth risking a failed update to fix. We'll be out of beta towards the end of the year, so I may do the upgrade then. Can I create a whole new server with the upgrade and then just copy the database? -djs On 10/26/2011 3:29 AM, Murphy, Alice wrote: > Perhaps we could compromise and have an extended version of the documentation, at least until the automated checks are written? We already have a quickstart set of instructions along with the standard version. > > However, rather than us writing automated checks in scripts, I'm wondering if something like Chef[1] or Puppet[2], with their infrastructure-as-code approaches, might be a better solution.
> > [1] http://wiki.opscode.com/display/chef/Home > [2] http://puppetlabs.com/ > ----------------------------------------- > Full text of this topic in GroupServer Development: > http://groupserver.org/r/topic/7ccjDXcgYgptRgB8Y86wru > > To leave GroupServer Development, email > <email obscured>?Subject=unsubscribe > > Start your own free groups and site with > OnlineGroups.Net http://onlinegroups.net > > Host your own online groups site with > GroupServer http://groupserver.org
David, I'd be really interested in seeing your process for installing GS on EC2. Would you mind posting it to the group for now, while we work out how best to present installation instructions?
Hi All,
I have updated the Installation Documentation¹. The Introduction
now states that email sending, web, and persistent storage have
to work for installation to succeed. I have also added a Download
section. There I discuss the location of the GroupServer directory,
and the need for the code to be owned by a normal user.
Steve,
The Download page², Installation page, and Release Notes³ have
*always* been editable to logged in members. (At least, that is
what the Permissions tabs for those pages says!) The Installation
Documentation that we ship with GroupServer *is* in a wiki format
(ReStructuredText); I will happily accept patches.
Alice,
I will get to Puppet in a bit. It deserves its own topic ☺
David,
Richard can tell you more about how we manage upgrades, if you
ask him. It involves using ZEO to share the ZODB between a Staging
instance and Production instance, allowing the update to be tested
before deployment. We normally upgrade this production server once
a fortnight.
*Footnotes*
1. Installation Documentation
<http://groupserver.org/downloads/install/>
2. Download Page <http://groupserver.org/downloads>
3. Release Notes <http://groupserver.org/downloads/release_notes/>
Several people have asked about my Groupserver installation on Amazon EC2. Here are my notes on the process from June 2011 with Groupserver v11.05 To install GroupServer on an ec2 instance 1) Set up an ec2 Ubuntu instance AMI: ebs/ubuntu-images/ubuntu-natty-11.04-i386-server-20110426 (ami-06ad526f) 2) Give it an Elastic IP 3) Set the security to allow - HTTP on port 80 and 8080 - SMTP on port 25 - SSH on port 22 4) Set up the users, secure the machine, etc. 5) Assume the URL you want do use groupserver with is http://groups.mydomain.com 6) Set the hostname - $ sudo /bin/hostname groups.mydomain.com - edit /etc/hosts and add an entry for the ec2 private IP address and groups.geanarts.com - 10.200.250.51 groups.mydomain.com 7) Follow instructions at http://www.groupserver.org/downloads/install up to the Zope install. - Install required packages - Install make as well (it's not on the list) - Configure PostgreSQL 8) Check that the mailname is set to groups.mydomain.com in /etc/mailname 9)Configure and test postfix - edit /etc/postfix/main.cf - add myhostname = groups.mydomain.com (May already be done if you've set the hostname before installing postfix) - add groups.mydomain.com to mydestination (May already be done if you've set the hostname before installing postfix) - add smtpd_authorized_verp_clients = 127.0.0.1 (See http://www.groupserver.org/groups/development/messages/topic/1Q0208eHA2vwhyTejj8nUc ) 10) Follow the instructions to install Zope - In the configuration step, set timezone = America/New_York 11) Follow the instructions to set up the email server - when you copy the postfix files to /etc/postfix, edit the groupserver.aliases so that the http URLs in the file use port 8080 example: verify-address: "|/home/username/groupserver-11.05/utils/smtp2zope-nonautomatic.py http://groups.mydomain.com:8080/acl_users/verify_address" group-automagic: "|/home/username/groupserver-11.05/utils/smtp2zope.py http://groups.mydomain.com:8080/ListManager" - Also remove the line groups.mydomain.com virtual from the file groupserver.virtual. Postfix doesn't like it in both mydestinations (in main.cf) and the virtual alias file 12) Set up a cron job to send out new messages. The following will run the groupserver outgoing mail spooler every minute. * * * * * curl -s http://groups.mydomain.com:8080/example/ListManager/processSpool FIXING BUGS 1) Fix the MailBoxerTools bug. See http://www.groupserver.org/groups/development/messages/post/4GybGchhpCJzZ0ONrBzDD1 - "The easiest way is to copy MailBoxerTools.py from BUILDOUT/eggs/Products.XWFMailingListManager-1.0_*/Products/XWFMailingListManager/ into your /var/gs/utils directory in which you have located smtp2zope." - However, /var/gs/utils may be ./utils in the installation directory. You need to look in the installation directory for where smtp2zope is. 2) You may want to add a root or personal address to groupserver.virtual so that you can test sendmail - For instance: root <email obscured> -or- username <email obscured> 3) Fix a problem with bounce messages that contain the zope admin login:password - edit the smtp2zope.py, and specify the authentication user/password in the AUTHORIZATION variable See http://groupserver.org/groups/development/messages/topic/62FhzQpK9DKLmDy0nI5i8E - However, this didn't seem to work. The following seemed to work for me: - Go into the ZMI and change the password there - Remove the login password from AUTHORIZATION in utils/smtp2zope.py. The line should look like AUTHORIZATION=' ' - Restart zope. If the password isn't in AUTHORIZATION in utils/smtp2zope.py it doesn't seem to show up in bounce emails 4) Announcement emails to admin about new members contains links with an extra "http://" - Go into the Zope console and edit the template /example/Templates/email/notifications/join_group_admin/default - Remove any "html://" in front of any <dtml-var "canonicalHost"> (since <dtml-var "canonicalHost"> already contains "html://"). 5) Check the log files. I've found files missing that need to be copied from one place to another. OTHER CONFIGURATIONS - Change the favicon - Replace /eggs/Products.GSContent-xxxx.egg/Products/GSContent/browser/images/favicon/gs-favicon-all-sizes.ico with your favicon. (xxxx is a long string of digits and chars.) - Restart zope - Configure Apache as a proxy on port 80 - Add the following to the top of /etc/apache2/sites-available/default <VirtualHost *> ServerName groups.mydomain.com RewriteEngine on RewriteRule ^(.*) http://groups.mydomain.com:8080/VirtualHostBase/http/groups.mydomain.com:80/example/Content/example_site/VirtualHostRoot/$1 [L,P] ErrorLog /var/log/apache2/groups.mydomain.com-error_log TransferLog /var/log/apache2/groups.mydomain.com-access_log ProxyVia on </VirtualHost> - Restart apache /etc/init.d/apache2 restart
-- DavidSturman - 2011-06-14
Hi David,
Thanks heaps for your instructions for how to get GroupServer going
on an Amazon E2C instance. In gs-e2c.txt and gs-e2c.html I have the
same instructions but in ReStructuredText¹ and HTML formats. (The
HTML was produced from the text.)
*Note* I re-formatted your instructions because I found it an easy
way to read and think about what you have written. For me
it is akin to reading a paper with a pencil in my hand. It
is not intended as a criticism of your generous work. I
posted the HTML because some may find it easier to read than
the text-only format of the post that GroupServer shows. I
posted the ReStructuredText because it is the source document
that I used to produce the HTML
I have not tried following your instructions. However, I would like to
clarify some things I do not understand.
* “Add an entry for the ec2 private IP address and groups.geanarts.com”
- Do you mean "groups.mydomain.com", or is groups.geanarts.com an
Amazon E2C thing?
* “Follow the GroupServer Installation Instructions up to the Zope
install”
- What section is that, David? Do you mean up to the point of
running Buildout?
* “Install make as well (it's not on the list)”
- The "make" package is a dependency of the "build-essential"
package, which is on the Requirements list in the GroupServer
Installation Instructions. Is there something specific about the
"build-essential" package on an Amazon E2C instance that means
that "make" is not a dependency?
* I appreciate the extra instructions on how to configure Postfix. Is
there anything specific about an Amazon E2C instance in them? I
failed to see anything, but I am not that good at configuring
Postfix! If your instructions are generic I will try and add them
into the main GroupServer Installation Instructions.
* “In the configuration step, set timezone = America/New_York.”
- Is there something specific about an Amazon E2C instance that
prevents GroupServer from working if the timezone is set to
a value other than New York?² Or did you set the timezone
to "America/New_York" for convenience? (which is a good and
reasonable thing to do!)
* “…edit the groupserver.aliases so that the http URLs in the file use
port 8080.”
- I do have a fix for that problem in place³. Sadly I have not had
a chance to make a release.
* I have created a ticket⁴ to remind me to fix the email template
so it does not contain an "http://" sequence.
* Your instructions for changing the Favicon will work, but any change
you make will only last until an upgrade of GroupServer. A more
durable solution would be to create a new skin, place your Favicon
in the new skin, and twiddle the configuration settings in your new
skin to replace the default Favicon.⁵
* Thanks for the Apache rewrite-rule. I am not skilled enough as an
administrator to tell if it is better or worse than the one in
"docs/apache-groupserver". What are the differences?
Thanks again, David!
*Footnotes*
1. ReStructuredText is the wiki format that Python, Zope, and
GroupServer use for documentation
<http://docutils.sourceforge.net/rst.html#user-documentation>.
2. Crazy timzeone issues have precedent. Apple iPhones had a bit of
a lie-down when Daylight Savings stopped in the Antipodes,
earlier this year. A part of Google (I forget which one) had an
issue where a UTC date caused things to fail.
3. <http://groupserver.org/r/post/4CHBiULpkTSdAxxg6Rw6qs>
4. Ticket 871: Fix New User Email Notification
<https://projects.iopen.net/groupserver/ticket/871>.
5. An example skin, and instructions for using it, are in this post
<http://groupserver.org/r/post/5yk1tciQS3tTVkX2wkuwxc>. The
Favicon is a resource, similar to a CSS file. Drop me a line
if you need a hand setting up your new skin.
* “Install make as well (it's not on the list)”
- The "make" package is a dependency of the "build-essential"
package, which is on the Requirements list in the GroupServer
Installation Instructions. Is there something specific about the
"build-essential" package on an Amazon E2C instance that means
that "make" is not a dependency?
I just found groupserver, THANKS. It looks great.
I decided to try it on Ubuntu server 11.10 since i read thats what you develop
on. make did not get installed as part of build essential. It may no longer be
a dependancy in later distributions of Ubuntu.
I usually use Centos and will try that next. Agin great package I look forward
to using it.
Ok, I will swap the "build-essential" requirement for "make".
Answers to Michael's questions: "Add an entry for the ec2 private IP address and groups.geanarts.com" Should be groups.mydomain.com. Geanarts is a typo from the domain I was using and so didn't get changed by my bulk replace. “Follow the GroupServer Installation Instructions up to the Zope install” This is up to but not including what is currently section "5 Set up Zope". I think I did it this way so that you get postfix and email all set up before you install Zope. I think Robert answered the make question... it doesn't seem to be a part of Ubuntu's build essential. I know little about Postfix. I just looked enough up on the web to get it working. I don't think there is anything special for EC2. My company's timezone is America/New York, so I used that. You could use anything, even NZ :-) Even though I was able to install and use the skin you sent me last June (thank you), I was never able to effectively modify it. I haven't been able to figure out the rules for what what inherits what and what I can change or where to change it. A skin built on a skin seemed to be even more complicated. I experimented a bit, but then ran out of time to figure it all out. I'm hoping for a manual of how to skin groupserver. Until then I resort to hacks like with the favicon or just accept things I cannot change. Perhaps if I was more familiar with Zope... As for the Apache re-write rule, I'm not sure what is the best, only that I tried a lot of things from the documentation, from advice on the internet, and playing around and found that my solution seemed to work. Finally, thanks for reformatting it. I had it all formatted for TWiki, but that didn't translate well to other formats.
-djs
Loading…
Privacy | Acceptable Use | Terms of Service | About OnlineGroups.Net | Contact OnlineGroups.Net
Start an OnlineGroups.Net site for easier email collaboration in your organization.
Powered by GroupServer, the open source web-based mailing list manager.