Hi,
I use Ubuntu 9.04 and these sites open no boubt. Also for some IE only sites you can use The User Agent Switch add on in Firefox (works in all OS)
Bye Regards
Subject: [ILUG-BOM] cant open certain in ubuntu 9.04 hi, i have recently installed ubuntu 9.04 , i cant open certainn websites like trade.hdfcsec, microsoft.com , i even installed xp via virtualbox but still cant open these sites ,i think some problems with network connection. my ip6 is enabled,kindly helpAshwani
Yahoo! recommends that you upgrade to the new and safer InternetExplorer 8. http://downloads.yahoo.com/in/internetexplorer/
Pravin Dhayfule wrote:
Hi,
I use Ubuntu 9.04 and these sites open no boubt. Also for some IE only sites you can use The User Agent Switch add on in Firefox (works in all OS)
The user agent switch is not good for FOSS. It gives a wrong impression to the developers that everyone is using IE. Better use IE for that.
On Sun, Jul 12, 2009 at 6:58 PM, Ronygnulinuxist@gmail.com wrote:
Pravin Dhayfule wrote:
Hi,
I use Ubuntu 9.04 and these sites open no boubt. Also for some IE only sites you can use The User Agent Switch add on in Firefox (works in all OS)
The user agent switch is not good for FOSS. It gives a wrong impression to the developers that everyone is using IE. Better use IE for that.
How? Installing IE4Linux through Wine? Then some people will say that's illegal. So what should users do? Install MS Windows just to browse sites which are supported only on IE? Don't you think that user agent switch is better than this?
On Monday 13 Jul 2009 10:31:20 am Abhishek Amberkar [अभिषेक] wrote:
I use Ubuntu 9.04 and these sites open no boubt. Also for some IE only sites you can use The User Agent Switch add on in Firefox (works in all OS)
The user agent switch is not good for FOSS. It gives a wrong impression to the developers that everyone is using IE. Better use IE for that.
How? Installing IE4Linux through Wine? Then some people will say that's illegal. So what should users do? Install MS Windows just to browse sites which are supported only on IE? Don't you think that user agent switch is better than this?
what he means is to boycott such sites.
IE Tab does not give the true impression of a IE on windows. I am referring to this month's issue of LinuxforU magazine, where they have mentioned about their experience in developing LFY magazine websitehttp://www.linuxforu.com/.
Thanks and regards,
Vivek M. Chaure
M. Tech.(C.S.E.) IIT Kharagpur. +919004911868
On Mon, Jul 13, 2009 at 10:41 AM, Kenneth Gonsalves lawgon@au-kbc.orgwrote:
On Monday 13 Jul 2009 10:31:20 am Abhishek Amberkar [अभिषेक] wrote:
I use Ubuntu 9.04 and these sites open no boubt. Also for some IE only sites you can use The User Agent Switch add on
in
Firefox (works in all OS)
The user agent switch is not good for FOSS. It gives a wrong impression to the developers that everyone is using IE. Better use IE for that.
How? Installing IE4Linux through Wine? Then some people will say that's illegal. So what should users do? Install MS Windows just to browse sites which are supported only on IE? Don't you think that user agent switch is better than this?
what he means is to boycott such sites.
regards Kenneth Gonsalves Associate NRC-FOSS http://nrcfosshelpline.in/web/ -- http://mm.glug-bom.org/mailman/listinfo/linuxers
On Mon, Jul 13, 2009 at 10:41 AM, Kenneth Gonsalveslawgon@au-kbc.org wrote:
On Monday 13 Jul 2009 10:31:20 am Abhishek Amberkar [अभिषेक] wrote:
I use Ubuntu 9.04 and these sites open no boubt. Also for some IE only sites you can use The User Agent Switch add on in Firefox (works in all OS)
The user agent switch is not good for FOSS. It gives a wrong impression to the developers that everyone is using IE. Better use IE for that.
How? Installing IE4Linux through Wine? Then some people will say that's illegal. So what should users do? Install MS Windows just to browse sites which are supported only on IE? Don't you think that user agent switch is better than this?
what he means is to boycott such sites.
Boycotting http://fyjc.org.in too?
On Monday 13 Jul 2009 12:32:20 pm Abhishek Amberkar [अभिषेक] wrote:
what he means is to boycott such sites.
Boycotting http://fyjc.org.in too?
yes
hello all, I am happy to announce that we are almost ready with the deb packages for gnukhata-client as well as server. Now we are facing a problem and I thought some one like JTD would already know a solution to my problem. I have been trying to make a demon for gnukhata's server and want it to run as the postgres user. I would ideally want this to be in the init.d for start, stop and restart. In addition most of the people would want this to start at system boot.
Can some one tell me how this is generaly done? does some one have a link to a tutorial which would teach this. Also I want to know if I want to run this demon as a dedicated user? For security reasons postgresql has a dedicated user by the name of postgres and this is the most recommended way of running the system. So while I would want the demon to auto start at system boot, i would surely like to know if some one knows to make a demon run as a specific user? I know this might be very simple but this is the first time I am doing some thing similar.
happy hacking. Krishnakant.
On Monday 13 Jul 2009, Krishnakant wrote:
[snip] I have been trying to make a demon for gnukhata's server and want it to run as the postgres user.
Bad idea. Please let the install script create a separate system user for gnukhata and enable that user to create databases, etc. in PgSQL. Running as the postgres user is _strongly_ deprecated.
Regards,
-- Raju
On Mon, 2009-07-13 at 13:53 +0530, Raj Mathur wrote:
On Monday 13 Jul 2009, Krishnakant wrote:
[snip] I have been trying to make a demon for gnukhata's server and want it to run as the postgres user.
Bad idea. Please let the install script create a separate system user for gnukhata and enable that user to create databases, etc. in PgSQL. Running as the postgres user is _strongly_ deprecated.
But this is what postgresql developres themselves are recommending. I personally know and even met of of the core developers of pg and he is also a consultent. He told me that the best thing to do is keep the postgres user as dedicated user which can access the database from only localhost. then you can have the xmlrpc server run on that same machine and so the remote clients just can't access the database directly, because the access is denyed.
happy hacking. Krishnakant.
On Monday 13 Jul 2009 2:09:06 pm Krishnakant wrote:
Bad idea. Please let the install script create a separate system user for gnukhata and enable that user to create databases, etc. in PgSQL. Running as the postgres user is strongly deprecated.
But this is what postgresql developres themselves are recommending. I personally know and even met of of the core developers of pg and he is also a consultent. He told me that the best thing to do is keep the postgres user as dedicated user which can access the database from only localhost. then you can have the xmlrpc server run on that same machine and so the remote clients just can't access the database directly, because the access is denyed.
I dont believe this. No one in his right mind would run anything by the 'postgres' user. One always runs with a dedicated user with the minimal possible rights - and rights *only* on the specific database in question.
On Mon, 2009-07-13 at 14:21 +0530, Kenneth Gonsalves wrote:
On Monday 13 Jul 2009 2:09:06 pm Krishnakant wrote:
Bad idea. Please let the install script create a separate system user for gnukhata and enable that user to create databases, etc. in PgSQL. Running as the postgres user is strongly deprecated.
But this is what postgresql developres themselves are recommending. I personally know and even met of of the core developers of pg and he is also a consultent. He told me that the best thing to do is keep the postgres user as dedicated user which can access the database from only localhost. then you can have the xmlrpc server run on that same machine and so the remote clients just can't access the database directly, because the access is denyed.
I dont believe this. No one in his right mind would run anything by the 'postgres' user. One always runs with a dedicated user with the minimal possible rights - and rights *only* on the specific database in question.
Yes, indeed we can have a dedicated gnukhata user and only keep it accessible from local machine and deny access from remote terminal.
happy hacking. Krishnakant.
Krishnakant wrote:
On Mon, 2009-07-13 at 13:53 +0530, Raj Mathur wrote:
On Monday 13 Jul 2009, Krishnakant wrote:
[snip] I have been trying to make a demon for gnukhata's server and want it to run as the postgres user.
Bad idea. Please let the install script create a separate system user for gnukhata and enable that user to create databases, etc. in PgSQL. Running as the postgres user is _strongly_ deprecated.
But this is what postgresql developres themselves are recommending. I personally know and even met of of the core developers of pg and he is also a consultent. He told me that the best thing to do is keep the postgres user as dedicated user which can access the database from only localhost.
I think you are confusing the role of the postgres user (which is responsible for running/managing the _postgres_ daemon) and a user that needs to use the DB.
I am assuming that in your case, the gunkhata daemon only needs to use the DB (ie: create, add, update ...etc the gnukhata database). So, in that respect, the gnukhata daemon would be a 'client' or a user in the postgres server.
However, to ensure that the gnukhata daemon which would have the ability to create databases on your postgres server, is isolated, you would ideally create a gnukhata user, like Raj Mathur suggested.
then you can have the xmlrpc server run on that same machine and so the remote clients just can't access the database directly, because the access is denyed.
This bit is correct, but it relates to the user that accesses the database.
HTH, - steve
On Mon, 2009-07-13 at 11:03 +0200, steve wrote:
Krishnakant wrote:
On Mon, 2009-07-13 at 13:53 +0530, Raj Mathur wrote:
On Monday 13 Jul 2009, Krishnakant wrote:
[snip] I have been trying to make a demon for gnukhata's server and want it to run as the postgres user.
Bad idea. Please let the install script create a separate system user for gnukhata and enable that user to create databases, etc. in PgSQL. Running as the postgres user is _strongly_ deprecated.
But this is what postgresql developres themselves are recommending. I personally know and even met of of the core developers of pg and he is also a consultent. He told me that the best thing to do is keep the postgres user as dedicated user which can access the database from only localhost.
I think you are confusing the role of the postgres user (which is responsible for running/managing the _postgres_ daemon) and a user that needs to use the DB.
I am assuming that in your case, the gunkhata daemon only needs to use the DB (ie: create, add, update ...etc the gnukhata database). So, in that respect, the gnukhata daemon would be a 'client' or a user in the postgres server.
yes that's the right asumtion.
However, to ensure that the gnukhata daemon which would have the ability to create databases on your postgres server, is isolated, you would ideally create a gnukhata user, like Raj Mathur suggested. Agreed.
Now the confusion is pritty clear to the developers I believe.
then you can have the xmlrpc server run on that same machine and so the remote clients just can't access the database directly, because the access is denyed.
This bit is correct, but it relates to the user that accesses the database.
So this means the dedicated user can be kept for local access same as the default postgres user.
This is fine and perfect. Now my next problem is, since I never created deb packages, need to know how I can automate this process of creating the db, creating the dedicated user and also setting a password if at all.
Right now I am managing to create a deb package which runs the setup.py (distutil ) for gnukhata. I altered the rules file for this. But now want to know how and where I put the code for creating the user and database?
happy hacking. Krishnakant.
On Monday 13 July 2009, Krishnakant wrote:
On Mon, 2009-07-13 at 11:03 +0200, steve wrote:
Krishnakant wrote:
On Mon, 2009-07-13 at 13:53 +0530, Raj Mathur wrote:
On Monday 13 Jul 2009, Krishnakant wrote:
[snip] I have been trying to make a demon for gnukhata's server and want it to run as the postgres user.
Bad idea. Please let the install script create a separate system user for gnukhata and enable that user to create databases, etc. in PgSQL. Running as the postgres user is _strongly_ deprecated.
But this is what postgresql developres themselves are recommending. I personally know and even met of of the core developers of pg and he is also a consultent. He told me that the best thing to do is keep the postgres user as dedicated user which can access the database from only localhost.
I think you are confusing the role of the postgres user (which is responsible for running/managing the _postgres_ daemon) and a user that needs to use the DB.
I am assuming that in your case, the gunkhata daemon only needs to use the DB (ie: create, add, update ...etc the gnukhata database). So, in that respect, the gnukhata daemon would be a 'client' or a user in the postgres server.
yes that's the right asumtion.
However, to ensure that the gnukhata daemon which would have the ability to create databases on your postgres server, is isolated, you would ideally create a gnukhata user, like Raj Mathur suggested. Agreed.
Now the confusion is pritty clear to the developers I believe.
then you can have the xmlrpc server run on that same machine and so the remote clients just can't access the database directly, because the access is denyed.
This bit is correct, but it relates to the user that accesses the database.
So this means the dedicated user can be kept for local access same as the default postgres user.
This is fine and perfect. Now my next problem is, since I never created deb packages, need to know how I can automate this process of creating the db, creating the dedicated user and also setting a password if at all.
Right now I am managing to create a deb package which runs the setup.py (distutil ) for gnukhata. I altered the rules file for this. But now want to know how and where I put the code for creating the user and database?
The link below explains nicely. http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/How-to-make-de...
On Mon, Jul 13, 2009 at 4:05 PM, jtdjtd@mtnl.net.in wrote:
The link below explains nicely. http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/How-to-make-de...
Good one for starters..
However, note that date of article is: 2003-10-24 and there are lots of changes in packaging policy after that. As, I said, if someone is making package, I will be glad and happy to test/review and making `official` Debian package for gnukhata.
On Mon, 2009-07-13 at 21:31 +0530, Kartik Mistry wrote:
On Mon, Jul 13, 2009 at 4:05 PM, jtdjtd@mtnl.net.in wrote:
The link below explains nicely. http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/How-to-make-de...
Good one for starters..
However, note that date of article is: 2003-10-24 and there are lots of changes in packaging policy after that. As, I said, if someone is making package, I will be glad and happy to test/review and making `official` Debian package for gnukhata.
GREAT. That is a bounty for us.
thanks a million. happy hacking. Krishnakant.
On Mon, 2009-07-13 at 16:05 +0530, jtd wrote:
On Monday 13 July 2009, Krishnakant wrote:
On Mon, 2009-07-13 at 11:03 +0200, steve wrote:
Krishnakant wrote:
On Mon, 2009-07-13 at 13:53 +0530, Raj Mathur wrote:
On Monday 13 Jul 2009, Krishnakant wrote:
[snip] I have been trying to make a demon for gnukhata's server and want it to run as the postgres user.
Bad idea. Please let the install script create a separate system user for gnukhata and enable that user to create databases, etc. in PgSQL. Running as the postgres user is _strongly_ deprecated.
But this is what postgresql developres themselves are recommending. I personally know and even met of of the core developers of pg and he is also a consultent. He told me that the best thing to do is keep the postgres user as dedicated user which can access the database from only localhost.
I think you are confusing the role of the postgres user (which is responsible for running/managing the _postgres_ daemon) and a user that needs to use the DB.
I am assuming that in your case, the gunkhata daemon only needs to use the DB (ie: create, add, update ...etc the gnukhata database). So, in that respect, the gnukhata daemon would be a 'client' or a user in the postgres server.
yes that's the right asumtion.
However, to ensure that the gnukhata daemon which would have the ability to create databases on your postgres server, is isolated, you would ideally create a gnukhata user, like Raj Mathur suggested. Agreed.
Now the confusion is pritty clear to the developers I believe.
then you can have the xmlrpc server run on that same machine and so the remote clients just can't access the database directly, because the access is denyed.
This bit is correct, but it relates to the user that accesses the database.
So this means the dedicated user can be kept for local access same as the default postgres user.
This is fine and perfect. Now my next problem is, since I never created deb packages, need to know how I can automate this process of creating the db, creating the dedicated user and also setting a password if at all.
Right now I am managing to create a deb package which runs the setup.py (distutil ) for gnukhata. I altered the rules file for this. But now want to know how and where I put the code for creating the user and database?
The link below explains nicely. http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/How-to-make-de...
JTD, the link does not open any page. Can you please confirm the link? happy hacking. Krishnakant.
On 7/14/09, Krishnakant krmane@gmail.com wrote:
On Mon, 2009-07-13 at 16:05 +0530, jtd wrote:
On Monday 13 July 2009, Krishnakant wrote:
On Mon, 2009-07-13 at 11:03 +0200, steve wrote:
Krishnakant wrote:
On Mon, 2009-07-13 at 13:53 +0530, Raj Mathur wrote:
<snip>
http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/How-to-make-de...
JTD, the link does not open any page. Can you please confirm the link? happy hacking.
KK, it works! But, its really old. Check out date, its 2003.
Krishnakant.
On Mon, Jul 13 2009, Krishnakant wrote:
On Mon, 2009-07-13 at 13:53 +0530, Raj Mathur wrote:
On Monday 13 Jul 2009, Krishnakant wrote:
[snip] I have been trying to make a demon for gnukhata's server and want it to run as the postgres user.
Bad idea. Please let the install script create a separate system user for gnukhata and enable that user to create databases, etc. in PgSQL. Running as the postgres user is _strongly_ deprecated.
But this is what postgresql developres themselves are recommending. I personally know and even met of of the core developers of pg and he is also a consultent. He told me that the best thing to do is keep the postgres user as dedicated user which can access the database from only localhost. then you can have the xmlrpc server run on that same machine and so the remote clients just can't access the database directly, because the access is denyed.
And running the xmlrpc server as a dedicated user, which only has access to the set of databases that it needs, is strictly better, and more secure, than openiong the full privileges of the postgres user.
Frankly, I am underwhelmed by the security acument of the said consultant developer.
manoj
On Mon, 2009-07-13 at 15:18 -0500, Manoj Srivastava wrote:
On Mon, Jul 13 2009, Krishnakant wrote:
On Mon, 2009-07-13 at 13:53 +0530, Raj Mathur wrote:
On Monday 13 Jul 2009, Krishnakant wrote:
[snip] I have been trying to make a demon for gnukhata's server and want it to run as the postgres user.
Bad idea. Please let the install script create a separate system user for gnukhata and enable that user to create databases, etc. in PgSQL. Running as the postgres user is _strongly_ deprecated.
But this is what postgresql developres themselves are recommending. I personally know and even met of of the core developers of pg and he is also a consultent. He told me that the best thing to do is keep the postgres user as dedicated user which can access the database from only localhost. then you can have the xmlrpc server run on that same machine and so the remote clients just can't access the database directly, because the access is denyed.
And running the xmlrpc server as a dedicated user, which onlyhas access to the set of databases that it needs, is strictly better, and more secure, than openiong the full privileges of the postgres user.
Frankly, I am underwhelmed by the security acument of the saidconsultant developer.
Yes, after all the emails and investigating in the issue further it seems that the alternative suggested by him was not the only way and perhaps not sufficient enough.
Any ways he is soon coming to India, we can arrest him for such an advice :)
happy hacking. Krishnakant.
On Tuesday 14 Jul 2009 10:27:17 am Krishnakant wrote:
Yes, after all the emails and investigating in the issue further it seems that the alternative suggested by him was not the only way and perhaps not sufficient enough.
I think he gave the correct advice and you misunderstood him. He probably said something like 'a dedicated postgres user', which meant a special user created by postgres that is dedicated to this particular database. You misunderstood it as 'the dedicated postgres user' which means the user named postgres.
On Tue, 2009-07-14 at 10:36 +0530, Kenneth Gonsalves wrote:
On Tuesday 14 Jul 2009 10:27:17 am Krishnakant wrote:
Yes, after all the emails and investigating in the issue further it seems that the alternative suggested by him was not the only way and perhaps not sufficient enough.
I think he gave the correct advice and you misunderstood him. He probably said something like 'a dedicated postgres user', which meant a special user created by postgres that is dedicated to this particular database. You misunderstood it as 'the dedicated postgres user' which means the user named postgres.
Yes perhaps the wrong words for the right solution. As a side note we indeed were looking at your ticket but did not close it because there were other major problems which we were facing and since we did not get any volantary support for deb packages and rpm, it is totally on me right now and that modules is also on my hands. We are also implementing schemas for projects , sub-projects and account heads so that large organisations fnd it easy to continue their methodology of seprate accounts bank, cash and other accounts for individual projects.
happy hacking. Krishnakant.
On Tuesday 14 Jul 2009 11:05:20 am Krishnakant wrote:
I think he gave the correct advice and you misunderstood him. He probably said something like 'a dedicated postgres user', which meant a special user created by postgres that is dedicated to this particular database. You misunderstood it as 'the dedicated postgres user' which means the user named postgres.
Yes perhaps the wrong words for the right solution. As a side note we indeed were looking at your ticket but did not close it
the one thing you must do is keep a close watch on tickets. Either accept them or reject them immediately. This encourages people to file tickets. They do not expect the ticket to be resolved immediately. They are just happy to know that they are not being ignored. Even rejection as wontfix or not a bug is also acceptable, but do it fast. Also I suggest that all issues you are facing should be filed as tickets. One ticket per issue. And if there is sufficient detail in the ticket you may be surprised to find patches appearing too.
as far as deb and rpm is concerned, it is not the job of a developer to make/maintain debs or rpms. If your application is any good, people will come forward to do that. In fact it is a good measure of the acceptability of your app if some one comes forward to package it. I suggest you do not waste your time on this.
On Tue, 2009-07-14 at 11:12 +0530, Kenneth Gonsalves wrote:
On Tuesday 14 Jul 2009 11:05:20 am Krishnakant wrote:
I think he gave the correct advice and you misunderstood him. He probably said something like 'a dedicated postgres user', which meant a special user created by postgres that is dedicated to this particular database. You misunderstood it as 'the dedicated postgres user' which means the user named postgres.
Yes perhaps the wrong words for the right solution. As a side note we indeed were looking at your ticket but did not close it
the one thing you must do is keep a close watch on tickets. Either accept them or reject them immediately. This encourages people to file tickets. They do not expect the ticket to be resolved immediately. They are just happy to know that they are not being ignored. Even rejection as wontfix or not a bug is also acceptable, but do it fast. Also I suggest that all issues you are facing should be filed as tickets. One ticket per issue. And if there is sufficient detail in the ticket you may be surprised to find patches appearing too.
Yes, we will follow this from now. I will forward this to the developers mailing list as well.
as far as deb and rpm is concerned, it is not the job of a developer to make/maintain debs or rpms. If your application is any good, people will come forward to do that. In fact it is a good measure of the acceptability of your app if some one comes forward to package it. I suggest you do not waste your time on this.
True, but people who are not linux experts want to install and test this. They are typicle end users and even after following installation instructions and personal helping over the phone, they find it difficult to install. People seem to be very used to double clicking an executable or at least do every thing in one 1 or 2 commands.
For getting the app tested by non-technical users, I really need to take up the responsibility of making packages. Else what you are suggesting is totally correct.
happy hacking. Krishnakant.
On Tue, 2009-07-14 at 11:12 +0530, Kenneth Gonsalves wrote:
On Tuesday 14 Jul 2009 11:05:20 am Krishnakant wrote:
I think he gave the correct advice and you misunderstood him. He probably said something like 'a dedicated postgres user', which meant a special user created by postgres that is dedicated to this particular database. You misunderstood it as 'the dedicated postgres user' which means the user named postgres.
Yes perhaps the wrong words for the right solution. As a side note we indeed were looking at your ticket but did not close it
the one thing you must do is keep a close watch on tickets. Either accept them or reject them immediately. This encourages people to file tickets. They do not expect the ticket to be resolved immediately. They are just happy to know that they are not being ignored. Even rejection as wontfix or not a bug is also acceptable, but do it fast. Also I suggest that all issues you are facing should be filed as tickets. One ticket per issue. And if there is sufficient detail in the ticket you may be surprised to find patches appearing too.
A couple of tickets have been added and your ticket is excepted (it is on me as usual ). So you can follow it up. even mehul's ticket has been excepted. happy hacking. Krishnakant.
On Monday 13 Jul 2009 1:53:38 pm Raj Mathur wrote:
On Monday 13 Jul 2009, Krishnakant wrote:
[snip] I have been trying to make a demon for gnukhata's server and want it to run as the postgres user.
Bad idea. Please let the install script create a separate system user for gnukhata and enable that user to create databases, etc. in PgSQL. Running as the postgres user is strongly deprecated.
I have posted a ticket and a patch for this - as far as I can see no one has even bothered to look at it. Just opening the code and putting a free license on it does not mean it is good code. You also need to respond to people who are trying to help out.
On Mon, Jul 13, 2009 at 1:34 PM, Krishnakantkrmane@gmail.com wrote:
hello all, I am happy to announce that we are almost ready with the deb packages for gnukhata-client as well as server. Now we are facing a problem and I thought some one like JTD would already know a solution to my problem. I have been trying to make a demon for gnukhata's server and want it to run as the postgres user. I would ideally want this to be in the init.d for start, stop and restart. In addition most of the people would want this to start at system boot.
Googling for "install startup service linux" (without the quotes) and "linux daemon howto" without quotes gave me this:
To write a daemon (you have probably done this already if you have written a server):
http://www.netzmafia.de/skripten/unix/linux-daemon-howto.html
To install it as a service:
http://bitnami.org/article/how-to-install-services-on-linux
For example scripts you can open any existing ones to see how they work. They are all in /etc/init.d in most common distros.
On Mon, 2009-07-13 at 13:54 +0530, Siddhesh Poyarekar wrote:
On Mon, Jul 13, 2009 at 1:34 PM, Krishnakantkrmane@gmail.com wrote:
hello all, I am happy to announce that we are almost ready with the deb packages for gnukhata-client as well as server. Now we are facing a problem and I thought some one like JTD would already know a solution to my problem. I have been trying to make a demon for gnukhata's server and want it to run as the postgres user. I would ideally want this to be in the init.d for start, stop and restart. In addition most of the people would want this to start at system boot.
Googling for "install startup service linux" (without the quotes) and "linux daemon howto" without quotes gave me this:
To write a daemon (you have probably done this already if you have written a server):
http://www.netzmafia.de/skripten/unix/linux-daemon-howto.html
To install it as a service:
http://bitnami.org/article/how-to-install-services-on-linux
For example scripts you can open any existing ones to see how they work. They are all in /etc/init.d in most common distros.
yes and there is one dummi script template which can be used as well from the same folder. Now I would want to know how this all can be automated in a deb package.
The catch here is that since our python app is getting installed using the distutils magic, we don't have a make file which will or any such file to perform compile and post conpile tasks. I don't think setup.py is the right place to put such things.
The rules file is a more appropriate place IMHO. happy hacking. Krishnakant.
On Mon, Jul 13, 2009 at 1:34 PM, Krishnakantkrmane@gmail.com wrote:
I am happy to announce that we are almost ready with the deb packages for gnukhata-client as well as server.
I will be happy to test them. However, can't commit for uploading it to Debian at moment..
Krishnakant wrote:
hello all, I am happy to announce that we are almost ready with the deb packages for gnukhata-client as well as server. Now we are facing a problem and I thought some one like JTD would already know a solution to my problem. I have been trying to make a demon for gnukhata's server and want it to run as the postgres user. I would ideally want this to be in the init.d for start, stop and restart. In addition most of the people would want this to start at system boot.
Make an executable startup script for the /etc/init.d folder. Then make a soft link to the same in the /etc/rc2.d folder using appropriate S numbers.
On Mon, Jul 13 2009, Krishnakant wrote:
hello all, I am happy to announce that we are almost ready with the deb packages for gnukhata-client as well as server. Now we are facing a problem and I thought some one like JTD would already know a solution to my problem. I have been trying to make a demon for gnukhata's server and want it to run as the postgres user.
Why? If you want there to be a DB that GNU Khata uses, the typical thing is to: a) Create a package specific user during initial install (i.e., there is no such user, and there is no previous version installed on the system) b) Depend on a database system b) Based on the system installed on the target machine, or a use choice via debconf, you run a script that 1) Creates the database 2) Populates its schema (create table, etc) 3) create a package specific user in the db 4) grant all access to the db created to said user.
I would ideally want this to be in the init.d for start, stop and restart. In addition most of the people would want this to start at system boot.
This is normal.
does some one have a link to a tutorial which would teach this. Also I want to know if I want to run this demon as a dedicated user?
You should.
For security reasons postgresql has a dedicated user by the name of postgres and this is the most recommended way of running the system.
Not if you want your package to actually get into Debian.
So while I would want the demon to auto start at system boot, i would surely like to know if some one knows to make a demon run as a specific user?
Look at clamav, et al. Most daemons do not run as root or as postgres.
I know this might be very simple but this is the first time I am doing some thing similar.
I think you need to program by example :-)
manoj
Abhishek Amberkar [अभिषेक] wrote:
On Mon, Jul 13, 2009 at 10:41 AM, Kenneth Gonsalveslawgon@au-kbc.org wrote:
On Monday 13 Jul 2009 10:31:20 am Abhishek Amberkar [अà¤à¤¿à¤·à¥‡à¤•] wrote:
I use Ubuntu 9.04 and these sites open no boubt. Also for some IE only sites you can use The User Agent Switch add on in Firefox (works in all OS)
The user agent switch is not good for FOSS. It gives a wrong impression to the developers that everyone is using IE. Better use IE for that.
How? Installing IE4Linux through Wine? Then some people will say that's illegal. So what should users do? Install MS Windows just to browse sites which are supported only on IE? Don't you think that user agent switch is better than this?
what he means is to boycott such sites.
Boycotting http://fyjc.org.in too?
If there is no way you can boycott a website, buy a legal XP Home and install it side by side and use IE legally or use your friend's machine. For everything else use Linux.
-
aamod nerurkar -
Abhishek Amberkar [अभिषेक] -
jtd -
Kartik Mistry -
Kenneth Gonsalves -
Krishnakant -
Manoj Srivastava -
Pravin Dhayfule -
Raj Mathur -
Rony -
Siddhesh Poyarekar -
steve -
Vivek Chaure