Re: Poll: Most helpful feature after 1.3?

[o1bigtenor <..hidden..>]

On Fri, Jul 22, 2011 at 2:21 PM, Chris Travers <..hidden..> wrote:
> 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.

Maybe it could be something like this:

Install postgresql x.xx.xx.
test that install by doing yyyyyyyyyy
result should be zzzzzzzzzzz

Then install ?????????
etc
etc

With each piece of software being check to verify that it is where it
needs to be and can and does communicate with all the other pieces
that are a part of the puzzle.

A what to do in case of error type of information is also a very useful tool

>>
>> 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.

As a user I am not aware of all of the differences (some subtle and
some not) between the different distros. It is not that easy to gain
this knowledge either!

>>
>>>
>>> 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.

Maybe what is needed is a virtual machine with everything set up on it.

I have been thinking that for a machine with enough horsepower that
this might be one way around needing to do all the steps oneself - -
that may be a null option - - what say you (devel team)?
>
>> 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?

Meta type meaning some kind of setup where all the various pieces were
being installed at one time (sequentially or whatever) by the setup
program versus setting up each piece individually.
>
> 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.
>
I am interested in helping - - if for nothing else than seeing how to
get it to not work (grin!).

I think I could also help with documentation.

One issue - - I am lots and lots of miles from anyone else that I know
that has high knowledge levels and I need my work system to be there
for running my businesses. (I do have three operational systems at the
present time and am only running two.)

Darald