On Thu, 5 Dec 2013 15:39:49 -0800 Chris Travers <chris.trav...@gmail.com> wrote:
> 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. 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 > > Ledger-smb-users@lists.sourceforge.net > > 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 Ledger-smb-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-users
