[SLUG] CGI/Perl Application - Speed Problems (SQL-ledger and Point-of-Sale)

2004-09-24 Thread Kirti Pankhania
Hi, all

Any SQL-ledger users at SLUG?

Re: POS - productlist, checkbox required instead of radio button

When picking product items, would it be possible to have checkboxes instead
 of radio buttons so that one can pick multiple items to build up the
 invoice? To select one item at a time takes ages.

The other issue is that every time the page is refreshed with a single new
 item, this can take from 5 to 25 seconds - despite the fact that user is on
 the local host, not on a remote terminal. Could this lack of speed be due
to  Apache not being tuned? For a ten or 20-item
 invoice it would take about 5 minutes to build up the invoice, because
 remember that a fresh product list is called up after choosing the last
 item. Any pointers? I suspect my 600 mhz CPU and 64mb ram is not the issue
as this is just a tiny demo database.

Are there any other good open-source POS programs out there?

On my laptop I have currently installed

1.Linux OS,
2.   Apache as the web Http server and
3.Postgresql as the database.

I also have an accounting application written in Perl which can use any
browser such as Mozilla or Explorer to access the database. The client and
browser can be remote.

The problem I am having is that with this setup, each page (text data only)
takes minimum 5 to 6 seconds to call up with the web server from the
database. Complex instructions take even longer - upto 30 seconds. There is
no difference whether the client is remote (say, on a Windows machine with
explorer browser) or on the same machine as the main DB and http server
(where I use a Mozilla browser).

My main objective is to have a shopping cart type of application that
responds quickly. I have the basic software infrastructure but how to make
it work efficiently is the issue. Perhaps I need to have Java mini
application at each client (?) - anyway I am not sure. How do these other
online shopping cart type of websites function with similar infrastructure?

 Ken




-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html


Re: [SLUG] CGI/Perl Application - Speed Problems (SQL-ledger and Point-of-Sale)

2004-09-24 Thread Matthew Palmer
On Sat, Sep 25, 2004 at 07:55:00AM +1000, Kirti Pankhania wrote:
 Any SQL-ledger users at SLUG?

There are at least two of us, although I don't think either of us are using
the POS functionality.

 When picking product items, would it be possible to have checkboxes instead
  of radio buttons so that one can pick multiple items to build up the
  invoice? To select one item at a time takes ages.

I presume it would be possible.  But this isn't the place to discuss this --
I'd keep it on sql-ledger-users.

 The other issue is that every time the page is refreshed with a single new
  item, this can take from 5 to 25 seconds - despite the fact that user is on
  the local host, not on a remote terminal. Could this lack of speed be due
 to  Apache not being tuned? For a ten or 20-item
  invoice it would take about 5 minutes to build up the invoice, because
  remember that a fresh product list is called up after choosing the last
  item. Any pointers? I suspect my 600 mhz CPU and 64mb ram is not the issue
 as this is just a tiny demo database.

I think that the 64MB of RAM is a possible cause of problems.  What else is
running on the machine?  Since you're running locally, your web browser is
probably chewing up all the core, causing Apache to have to swap out, then
swap in to service the request, then swap out to allow the browser to swap
back in to display the result, and so on and so forth.  Installing
SQL Ledger on a machine which isn't overcommitted might be a good start, or
at least determining (through top or whatever) whether your Apache is in
fact swapping and frothing.

I say this as someone whose SQL Ledger setup is running on a 64MB P166 (pure
server, though, with no X or web browser or anything else chewing up all the
RAM) and who hasn't noticed any 5-25 second delays while creating invoices
(and I'd get pissed off if I had them, because I'm an impatient kind of
guy).

- Matt


signature.asc
Description: Digital signature
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

RE: [SLUG] CGI

2002-03-26 Thread Hartono, Susanto

Yes. Assuming the ip address is 10.10.10.10 then it will be 

http_access allow manager localhost 10.10.10.10
http_access deny manager

I am not sure what version of squid you are running but you might also want
to specify which actions are allowed via cachemgr.cgi in squid.conf. Format
is something like (taken straight from my squid.conf file):

#Example:
# cachemgr_passwd secret shutdown
# cachemgr_passwd lesssecret info stats/objects
# cachemgr_passwd disable all

Good luck.


-Original Message-
From: Adam Hewitt [mailto:[EMAIL PROTECTED]]
Sent: Monday, 25 March 2002 9:07 PM
To: Hartono, Susanto
Cc: [EMAIL PROTECTED]
Subject: RE: [SLUG] CGI


I assume that 'allowed-ip-address' is actually the IP address that Im 
allowing not the actual words you have typed their??

http_access allow manager localhost allowed-ip-address
http_access deny manager

-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug



RE: [SLUG] CGI

2002-03-25 Thread Adam Hewitt

I assume that 'allowed-ip-address' is actually the IP address that Im 
allowing not the actual words you have typed their??

http_access allow manager localhost allowed-ip-address
http_access deny manager


-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug



[SLUG] CGI

2002-03-24 Thread Adam Hewitt

Hi,

Ok I think I have gotten to a point where the squid-cgi (or cachemgr.cgi) 
is working, however I am not able to connect, and I am getting a You are 
not authorized to view this page You might not have permission to view this 
directory or page using the credentials you supplied. error. Could someone 
please tell me which files may be setup incorrectly in order to give me 
access...I have added the following to my srm.conf file:

ScriptAlias /cgi-bin/ /usr/local/cgi-bin/

and this to my access.conf file:

Location /Squid/cgi-bin/cachemgr.cgi
order deny,allow
deny from all
allow from 192.168.0.1
/Location

is this all I need??

Adam.



-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug



Re: [SLUG] CGI

2002-03-24 Thread Jessica Mayo

On Sun, 24 Mar 2002, Adam Hewitt wrote:
 please tell me which files may be setup incorrectly in order to give me 
 access...I have added the following to my srm.conf file:
 
 ScriptAlias /cgi-bin/ /usr/local/cgi-bin/
 
 and this to my access.conf file:
 
 Location /Squid/cgi-bin/cachemgr.cgi
 order deny,allow
 deny from all
 allow from 192.168.0.1
 /Location

I've never installed squid before, but something doesn't look right
here...

There should be something matching up in what you've added to both files.
Check exactly where cachemgr.cgi is on the harddisk.

From what I see above, I'm expecting it will be in /usr/local/cgi-bin,
in which case the scriptalias line is wrong.

Try this line instead:

ScriptAlias /Squid/cgi-bin/ /usr/local/cgi-bin/

It is also possible that apache just isn't set up to allow cgi scripts.
There is fairly good comments in the apache config files, but look for a
line something like ScriptHandler .cgi ... It's probably commented out.
Delete the hash sign in front and restart apache.

Another possibility is that you're not getting through the 'allow from'
filter. is 192.168.0.1 your local machine? TCP/IP connections within your
local machine usually end up being from 127.0.0.1, rather than the address
of your ethernet card.

I might be able to come up with some more ideas. Let me know how you go.

-- Jessica Mayo.
(Everything with a Grin :)

-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug



Re: [SLUG] CGI

2002-03-24 Thread Daniel Stone

On Sun, Mar 24, 2002 at 08:43:39PM +1100, Adam Hewitt wrote:
 order deny,allow
 deny from all
 allow from 192.168.0.1

Swap the order of these last two lines. Here, you're saying deny
everything, and then allow 192.168.0.1 if no decision's been made.
Either that, or change the first line to be order allow,deny.

-- 
Daniel Stone[EMAIL PROTECTED]
Md Booting... /vmunix.el



msg21906/pgp0.pgp
Description: PGP signature


RE: [SLUG] CGI

2002-03-24 Thread Chris Barnes

Firstly, I think your order of deny's and allow's is important...if you have
deny all before allow 192.168.0.1 then it 192.168.0.1 will be denied...if
you put allow from 192.168.0.1 then deny all, if will check if the request
is coming from 192.168.0.1, if not it will deny all...i know that sounds
really vague but that about the best I can explain it at 10 to four in the
morning.

Try that tell us what happensI know I've use the cachemgr.cgi once or
twice before but never really had enough troubles to really look into how it
works.
--

-Original Message-
From: Adam Hewitt [mailto:[EMAIL PROTECTED]] 
Sent: Sunday, 24 March 2002 8`44 PM 
To: [EMAIL PROTECTED]
Subject: [SLUG] CGI

Hi,

Ok I think I have gotten to a point where the squid-cgi (or cachemgr.cgi) 
is working, however I am not able to connect, and I am getting a You are 
not authorized to view this page You might not have permission to view this 
directory or page using the credentials you supplied. error. Could someone 
please tell me which files may be setup incorrectly in order to give me 
access...I have added the following to my srm.conf file:

ScriptAlias /cgi-bin/ /usr/local/cgi-bin/

and this to my access.conf file:

Location /Squid/cgi-bin/cachemgr.cgi
order deny,allow
deny from all
allow from 192.168.0.1
/Location

is this all I need??

Adam.



-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug

Searching for A Better Way to a home loan ?. Call RAMS on 13 7267, or go to 
http://www.rams.com.au

The e-mail and any attachments may contain confidential information.  If you receive 
it in error you must not use or disclose the information. You must tell us and delete 
it. We do not waive any legal privilege by sending it. RAMS does not promise that the 
email is free from virus defect or error.
-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug



RE: [SLUG] CGI

2002-03-24 Thread Hartono, Susanto

-Original Message-
From: Adam Hewitt [mailto:[EMAIL PROTECTED]]

I am assuming your squid.conf file already has these entries in it?

http_access allow manager localhost allowed-ip-address
http_access deny manager

-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug



Re: [SLUG] CGI

2000-07-17 Thread Peter Faulks

On Fri, 14 Jul 2000 14:42:23 +1000, Matt Kozera wrote:

Why dont you just ring up anonymously* and ask them why they
support it ? Then report back to the list, i'm dying to know 
why they wont support it, Agent 62 8[

I rang them this morning (I only found out who they were yesterday arvo).

Techie - 'I have nothing against it (PHP) myself, but management has said that they
will not support it now or in the future'

Me - 'Can I ask why?'

Techie - 'I don't know the reason'

BTW it is a Linux shop



--
FormViewer - view your form from many angles
Version 1.05 now available
http://www.cia.com.au/pfaulks




--
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug



Re: [SLUG] CGI

2000-07-14 Thread Matt Kozera

Peter Faulks wrote:
 
 G'day Sluggers,
 
 I've been offered a job to write a CGI programme.
 
 The client's ISP has a company policy against the use of PHP.
 Are there known security issues with PHP?
 

Very interesting ! Very weird ! :)

It could be said that PHP is relatively new and therefore not
refined with its security. Then again they could be using a
Winblows (haha he hehe HEH ehehe heh) server in which case they
might not trust it running it ? I dunno. 

Why dont you just ring up anonymously* and ask them why they
support it ? Then report back to the list, i'm dying to know 
why they wont support it, Agent 62 8[



Regards, Matt


* ftp clients teach *YOU* new words


--
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug



[SLUG] CGI

2000-07-13 Thread Peter Faulks

G'day Sluggers,

I've been offered a job to write a CGI programme.

The client's ISP has a company policy against the use of PHP.
Are there known security issues with PHP?

Also, are there any security issues with fast cgi (Apache/mysql)?
I had a quick look at the source, it seems to me there are a few 
places where buffer overrun could be induced, but I haven't really
had a good look yet.

I like the concept of fast cgi, ie no database connect/disconnect 
every time a cgi request comes in, but I hear fast cgi hasn't really
taken off..  Comments?

Regards




'The day Microsoft makes something that doesn't suck is the day
  they start making vacuum cleaners.' 




--
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug



Re: [SLUG] CGI

2000-07-13 Thread Dean Hamstead

I find it inconceivable a company would have a policy against PHP,
maybe against
ASP...

perl / mysql is damn good, i recommend it
i would also have to recommend java (eg. servlets and JSP)
which makes an incredibly good environment.

Dean

Peter Faulks wrote:
 
 G'day Sluggers,
 
 I've been offered a job to write a CGI programme.
 
 The client's ISP has a company policy against the use of PHP.
 Are there known security issues with PHP?
 
 Also, are there any security issues with fast cgi (Apache/mysql)?
 I had a quick look at the source, it seems to me there are a few
 places where buffer overrun could be induced, but I haven't really
 had a good look yet.
 
 I like the concept of fast cgi, ie no database connect/disconnect
 every time a cgi request comes in, but I hear fast cgi hasn't really
 taken off..  Comments?
 
 Regards
 
 'The day Microsoft makes something that doesn't suck is the day
   they start making vacuum cleaners.'
 
 --
 SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
 More Info: http://slug.org.au/lists/listinfo/slug

-- 
BONG: http://www.bong.com.au
EMAIL...
[EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED]  [EMAIL PROTECTED]
ICQ: 16867613


--
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug



Re: [SLUG] CGI

2000-07-13 Thread Graeme Merrall

Peter Faulks wrote:

 The client's ISP has a company policy against the use of PHP.
Why? Are the ASP/IIS fans? :)

 Are there known security issues with PHP?
Nope. You can even lock it down more by specifying safe mode and doing
various bits and bobs in the compilation and cojnfiguration such as
discarding redirection heading. Have a look at
http://au.php.net:81/manual/html/security.html

 I like the concept of fast cgi, ie no database connect/disconnect
 every time a cgi request comes in, but I hear fast cgi hasn't really
 taken off..  Comments?
A lot of the cgi 'bolt-ons' don't seem to have gathered much support -
that's true. MOst people are happy to use mod_perl/php etc.

Cheers,
 Graeme


--
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug



Re: [SLUG] CGI

2000-07-13 Thread Matt Allen

Gday Peter,

There is a new feature in PHP 4.0.1 where the ISP can shutdown any function of
PHP from within the php.ini file.

Its weird that they allow "CGI" but not PHP. You can get just as malicious with
Perl as you can with PHP. Of Course, they should be running the CGI under SuEXEC
so you only get the rights of your user anyway.

Matta

Peter Faulks wrote:
 
 G'day Sluggers,
 
 I've been offered a job to write a CGI programme.
 
 The client's ISP has a company policy against the use of PHP.
 Are there known security issues with PHP?
 
 Also, are there any security issues with fast cgi (Apache/mysql)?
 I had a quick look at the source, it seems to me there are a few
 places where buffer overrun could be induced, but I haven't really
 had a good look yet.
 
 I like the concept of fast cgi, ie no database connect/disconnect
 every time a cgi request comes in, but I hear fast cgi hasn't really
 taken off..  Comments?
 
 Regards
 
 'The day Microsoft makes something that doesn't suck is the day
   they start making vacuum cleaners.'
 
 --
 SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
 More Info: http://slug.org.au/lists/listinfo/slug

-- 
Matt Allen  Linux/PHP eCommerce Solutions
Linux Worx  Linux Networking
www.linuxworx.com.auConsulting
[EMAIL PROTECTED]   
0413 777 771


--
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug