On Thu, Dec 5, 2013 at 7:29 AM, ario <ledger-smb-us...@infopower.nl> wrote:
> On Thu, 5 Dec 2013 05:54:43 -0800
> Chris Travers <chris.trav...@gmail.com> wrote:
>
> > On Thu, Dec 5, 2013 at 4:33 AM, ario <ledger-smb-us...@infopower.nl>
>
> >
> > >
> > > In my setup it goes wrong when I connect to port 5432.
> > > So, I was thinking, httpd would have to know what to do with port
> > > 5432.
> > >
> >
> > Actually HTTP hands it off to LSMB which hands it off (indirectly) to
> > the PostgreSQL client libraries, effectively. It's slightly more
> > complex than that, but that's a general idea.
>
> Ok, but, my point was: If I do a page request
> (http://127.0.0.1:5432/ledgersmb), how does httpd know
> 1. to listen to port 5432 without being instructed to do so?
>
httpd does not listen on port 5432. That's the port PostgreSQL listens on.
> 2. to only pass the request through to lsmb if it comes through port
> 5432?
>
No. httpd listens on port 80. It hands requests for certain url's to
LedgerSMB which talks to PostgreSQL.
> t.
>
> Yes, but according to which conf file?
>
> > If you want to change the port, you do it
> > in the ledgersmb.conf in your ledgersmb directory (for example,
> > /usr/local/ledgersmb/ledgersmb.conf). The client libraries use 5432
> > if no other port is specified.
>
> My intuition tells me that httpd should be specifically instructed to
> allow connections on 5432, and to funnel only those connections to
> 'ledgersmb'.
> In my config files I couldn't find any setting of 5432, and, as a
> consequence I think, and what I posted somewhere else in this thread,
> my system only gives me the login and setup screen if I connect on
> port 80 to ledgersmb.
> And I have no idea why my F18 system seems to
> behave so differently (it's not the first time I tried to install lsmb
> on F18, until today to no avail--but hey, back then I didn't even try
> to connect simply through port 80), except for that one little
> commented-out remark in /var/lib/pgsql/data/postgresql.conf file, that
> on Fedora/RHEL/CentOS listening on port 5432 should be accounted for
> not there, but in the 'service file', whatever they might mean by that
> vague indication.
>
>
>
>
> > > I'm afraid this means I absolutely don't understand what's going
> > >> > on,
> > > i.e. as a start, how httpd works.
> > >
> >
> > 5 min. introduction (probably better at the -devel list but oh well):
> >
> > 1. httpd receives your browser's request.
> > 2. httpd hands it off to ledgersmb, either as a CGI script, or via
> > FCGI. 3.
>
> I never worked with, nor do I understand or 'speak', CGI, but wasn't it
> a perl file login.pl?
>
All CGI and FCGI are:
specifications for programs to talk to web servers. Apache speaks HTTP,
CGI, FCGI, etc. LedgerSMB speaks CGI/FCGI and PostgreSQL.
>
> > LedgerSMB connects to the db, does what you need it to and
> > then disconnects. It returns its output to httpd.
> > 4. httpd sends that output to your browser.
> >
> >
> >
> > > Time for the documentation, I guess...
> > >
> >
> > I am wondering if there would be interest for entry level LedgerSMB
> > courses, perhaps over Skype, or with video/screencasts with some
> > extra one on one time. It might be a good way to help provide a
> > basic understanding of how everything works together, etc, allow for
> > a little direct instruction, and the like.
>
> I think a shortlist with a detailed) layout of the (default) structure
> of the system would already be very helpful.
> I.e. something like:
> A page request reaches the server, which is instructed through 'a'
> conf file (in this case 'ledgersmb.conf', but I feel
> it could have any name as long as the content makes
> it work) in /etc/http/conf.d/ to call the ledgersmb login.pl
> in /usr/share/pgsql/ IF the request comes in on port 5432.
> This login script then logs into the pgsql server which, instructed
> through its pg_hba.conf in /var/lib/pgsql/data/ allows the login.
>
> Or some sheets with a graphical presentation of the default setup
> with absolutely clear pointers of what is where and what has which
> user/permission settings would also make things easier to understand
> (and more difficult to mess up).
>
Part of the problem (and why I am wondering if courses would be a good
idea) is that each of these levels is relatively complex in terms of what
you can do with it. For example, Bob Miller has put together a great
discussion on how to authenticate LedgerSMB against OpenLDAP. This
requires an understanding of how PostgreSQL, Apache, and LedgerSMB work
together, and the capabilities of each.
As far as understanding how things fit together, as we move towards better
PSGI support (another specification for Perl programs talking to web
servers) and others, this will actually get more complex. Is LedgerSMB
running inside Apache? Cached as separate processes? Something else?
These become implementation decisions which require someone who has a
strong understanding of implementing the software to decide.
> In order that people don't need to be a developer in order to
> understand what's going on. Something with boxes, arrows and config
> file entries for clarification of the structure of the whole process.
> I am missing this, but in no way am I asking you to provide such
> documentation. Especially not now it seems to (almost) work here :)
>
I think if you start by reading the PostgreSQL documentation, and read
about what CGI is, that would probably be the best place to start. I am
certainly not against putting in effort to improve the documentation but
there are limits I think to what can be accomplished there. Most of the
time "how it all works" is kind of developer documentation anyway. What
you really need to know is what the pieces generally expect from eachother.
Here's another way of putting the 5 min overview.
1. Your browser talks to Apache over port 80 or 443.
2. Apache tells LedgerSMB about the request using one of a number of means
available, generally not network sockets though. For example, with CGI, it
just invokes the program as it it is a command-line program.
3. LedgerSMB connects to the db and uses it.
4. LedgerSMB tells Apache what to send to your browser.
5. Apache sends your web browser the information.
Hope this helps.
>
>
> Kind regards and thanks for the great job of giving us lsmb,
> ario
>
>
>
>
>
> ------------------------------------------------------------------------------
> Sponsored by Intel(R) XDK
> Develop, test and display web and hybrid apps with a single code base.
> Download it for free now!
>
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
> _______________________________________________
> Ledger-smb-users mailing list
> Ledger-smb-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ledger-smb-users
>
--
Best Wishes,
Chris Travers
Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor
lock-in.
http://www.efficito.com/learn_more.shtml
------------------------------------------------------------------------------
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
_______________________________________________
Ledger-smb-users mailing list
Ledger-smb-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-users
