Re: Poll: Most helpful feature after 1.3?

[Chris Travers <..hidden..>]

Ok.  Getting further into this which is good :-)


On Fri, Jul 22, 2011 at 11:45 AM, o1bigtenor <..hidden..> wrote:

> I used files from .deb repositories for each of the installations.
>
> I have used apt-get I have also used aptitude. Each seemed to get
> whatever job done but then came the issues.
>
> This work was last summer - - thinking June/July 2010.
>
> My contact actually wrote a perl script which worked through all the
> steps as his final attempt. It was because of this script that I got
> to where everything was installed. I think that he spent a lot of time
> on that script that I didn't pay for because he wanted to get things
> to work - - he hates to leave something not completed.
>>>
>>> It was assumed that you had Postgres running.
>>> It was assumed that you had all the associated programs (like psql)
>>> running and correctly linked.
>>
>>
>> Before getting into where we might be able to improve the
>> documentation based on your feedback, one issue is worth mentioning
>> regarding the tarballs.  The tarballs are intended to be installed on
>> a wide range of operating systems (they should be able to be installed
>> on various UNIX systems, Windows, Linux, BSD, etc).  So I don't think
>> we will ever be able to provide comprehensive distro-specific
>> instructions anywhere.  On top of that, the Debian specific
>> documentation is not authored by me.  Generally I have assumed that
>> packages solve this problem (.debs), but I also recognize that since I
>> am not a Debian user, those will have to be packaged by someone else.
>>
>> This being said, your comments suggest there is room for improvement.
>> First, I don't know if there were .debs available at that time, but if
>> there were maybe we didn't do a good enough job of making sure people
>> knew about them.  Secondly it might be worth adding a "before you
>> begin" checklist.  Things like "Make sure PostgreSQL is installed and
>> running and that you can access it with psql."  As well as suggestions
>> as to where to find additional documentation if you run into trouble.
>
> Wouldn't be even better to have a .deb or .rpm that went like this:
>
> 1. you want to run LedgerSMB
> 2. you do not have Postgres running
> 3. you do not have Apahe running
> 4. run this script
> 5. enter passwords as required by the script
> 6. start the service
> 7. enter a password for the superuser and a user for ledgerSMB
> 8. run

I don't know the debian packaging system well enough to answer that
question (there are others on this list who hopefully light step up)
but for rpm's it is possible to throw warnings.  This is complicated a
bit by the fact that people may want to run the web application on a
different server from the database side.  So I am not necessarily sure
it is a good idea to throw warnings because the db server is not
running on the same box as the rpm or deb install.

So barring that, the question becomes what we can do to help here.
Here is my thinking:

1)  Place pre-install and installation documentation in the
Sourceforge.net package directory so it's obvious where it is.
2)  Install appropriate documentation into the appropriate folders,
and perhaps provide a link to an installation file in the event that
errors are triggered from the login script.

Right now we may not know what the problem with the login was.  My
immediate thoughts are different from yours but I could be wrong.


>
> The script my contact wrote did everything to step 6. It was after
> that that I couldn't get the program to actually run so I could set up
> my COA etc.

There are two other things that could have prevented this as well.
The first is if PostgreSQL had not been configured to use password
authentication (many distros including, I think, Debian by default
requires that the user be logged in under a specific system account to
log in), and the second is if it had, but a password had not been set
up.  In either of these cases you wouldn't have been able to log in.
In general if you know something about PostgreSQL, this is obvious,
but as you point out, we don't want to make that assumption.

Moreover, this absolutely must be documented better for 1.3 because
the way we authenticate users means that we have fewer choices for
supported authentication settings for PostgreSQL.  A little knowledge
might have been passable in 1.2 in lieu of better documentation but in
1.3 it can pose security hazards.  What I can tell you is that this is
being worked on and so the description of your problem is very timely
and helpful.
>
>>
>> It might also be worth pointing out this list as a place for install help.
>>
>>> It was assumed that you had Apache running.
>>> It was assumed that you knew how to make these programs work harmoniously.
>>> It was assumed that if anything didn't install correctly that you
>>> would KNOW how to fix the issues and repair the now broken install.
>>
>> >From these comments it sounds like you may have into the
>> incompatibility with a feature of Apache (SUExec) that we inherited
>> from SQL-Ledger.  This was only recently reported to us and we got it
>> corrected in the most recent release, not that this helps you now.
>> Maybe if we push the list as a place to get installation help these
>> problems will be reported and fixed sooner.
>
> I didn't respond any sooner because I've heard RTFM lots of times and
> so have gotten quite used to flailing around beating my head against
> the wall in trying to determine what it is that I need to do next. Its
> also why I went to my contact - - he's a materials engineer by
> training and works in  I don't know how many languages so when
> something stumps him - - well I won't even bother trying. I also
> didn't want to spent $500+ just to install either. I do know that I
> spent well over 25 hours working on things and my contact probably did
> about 6 to 8 hours because he investigated the source code and said it
> was quite an improvement re: its predecessor which he that previously
> looked at.

Ok.  For the record, I have no current plans to increase my rates from
$60 for a basic install on UNIX/Linux (getting the software up and
running, and optionally your database set up with a chart of accounts
of your choice).  The price is likely to be about double that on
Windows.

> I wanted something with lots of horsepower under the hood because I
> have 3 businesses that I'm running and one of those I want lots of
> background info stored with the ledger and I was thinking of adding
> some BLOB areas so that I could enhance the usefulness of the ledger
> as a management tool. (As I used 251 columns in the spreadsheet
> version of my ledger from 1997 or 1998 I think I qualify as at least
> somewhat anal about information!)

One thing I'd highly recommend is that if you choose to add some
functionality, everyone is better off if we talk about it (here and on
-devel) first.  If changes get shared it cuts down on your maintenance
efforts.

>
> Some of this is now quite difficult. I had a computer lockup - created
> by installing a program (trying to actually) and I had to ssh into it
> and download my files onto the present machine. The previous has a new
> operating system (Ubuntu 11.04 and I hate the panel or whatever they
> are calling it - - and I can't figure out how to change it!) so I will
> check and see if the script is still available.
>
> A script which would just install and setup all the requisite programs
> would be my preferred solution.

I am going to sit and thing about this a bit more.
>
> Others might see a need for less meta type methods but for those that
> are more users (rather than under the hood types) I think you might
> get a very positive response. Those that are the 'under the hood
> types' would be most likely quite able to proceed on their own.

I am not at all certain what you mean by meta type methods.  Can you
be specific?

Also one thing I want to be absolutely clear about.  I am not
criticizing your handling of anything.  Rather I am trying to
understand what we can do better.

Best Wishes,
Chris Travers