[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: postgresql settings in fedora 18?






On Thu, Dec 5, 2013 at 7:29 AM, ario <..hidden..> wrote:
On Thu, 5 Dec 2013 05:54:43 -0800
Chris Travers <..hidden..> wrote:

> On Thu, Dec 5, 2013 at 4:33 AM, ario <..hidden..>

>
> >
> > 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
..hidden..
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
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-users