Re: postgresql settings in fedora 18?

[ario <..hidden..>]

On Thu, 5 Dec 2013 15:39:49 -0800
Chris Travers <..hidden..> wrote:

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

Sorry, I was always connecting to port 5432 in 1.21.x.
So that has changed to port 80?
No wonder it didn't work until by chance I connected to port 80.

Problem solved! Thanks.

ario


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


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