Support A2Billing :

provided by Star2Billing S.L.

Support A2Billing :
It is currently Wed Nov 13, 2019 10:25 pm
Predictive Dialer


All times are UTC




Post new topic Reply to topic  [ 8 posts ] 
Author Message
 Post subject: Problem with backups not working (v1.2.3)
PostPosted: Fri Feb 09, 2007 4:18 am 
Offline

Joined: Tue Nov 21, 2006 7:01 pm
Posts: 19
I've found a problem in the backup process (version 1.2.3). Symptoms are the backup appears instantaneous but nothing is backed up. No error message, and the backup is added to the restore list but of course cannot be restored because it never existed.

I've traced it to the Public/form_data/FG_var_backup.inc file, where the pg_dump command is executed. On line 24 & 25, the environment variable PGPASSWORD is set so that it will be available to the pg_dump command called on line 30 and the backup will succeed. But on my system at least, the env var set isn't working, therefore the pg_dump fails.

My fix is to combine the PGPASSWORD env var command with the pg_dump command. To implement this, replace these three lines:

$env_var="PGPASSWORD='".PASS."'";
putenv($env_var);
$run_backup=PG_DUMP." -c -d -U ".USER." -h ".HOST." -f \
".$backup_file." ".DBNAME;

with this one:

$run_backup="PGPASSWORD='".PASS."' ".PG_DUMP." -c -d -U ".USER." \
-h ".HOST." -f ".$backup_file." ".DBNAME;

Running diff -u gives me this:

--- FG_var_backup.inc 2007-02-08 15:35:02.000000000 -0800
+++ FG_var_backup.inc.original 2007-02-08 15:23:09.000000000 -0800
@@ -21,7 +21,9 @@
if (DB_TYPE != 'postgres'){
$run_backup=MYSQLDUMP." -all --databases ".DBNAME." -u".USER." -p".PASS." > ".$backup_file;
}else{
- $run_backup="PGPASSWORD='".PASS."' ".PG_DUMP." -c -d -U ".USER." -h ".HOST." -f ".$backup_file." ".DBNAME;
+ $env_var="PGPASSWORD='".PASS."'";
+ putenv($env_var);
+ $run_backup=PG_DUMP." -c -d -U ".USER." -h ".HOST." -f ".$backup_file." ".DBNAME;
}

if ($FG_DEBUG == 1 ) echo $run_backup."<br>";

Hope this is of some help.

Timbo


Top
 Profile  
 
 Post subject:
PostPosted: Fri Feb 09, 2007 7:34 pm 
Offline

Joined: Thu Oct 19, 2006 9:56 am
Posts: 300
Location: Athens, Greece
This practice is, I'm afraid, false.
You are never supposed to supply passwords to commands in their command line. Every user in the system has the right to read out the cmdline, and therefore the password.

One alternative would be to let postgres trust all local users (see pg_hba.conf). In fact, trusting all local users is even more secure than having a password in the cmdline.

I'm looking into the matter for an even better solution.
Edit: read /usr/share/doc/postgresql-docs-8.2.0/libpq-pgpass.html

One more note: we're telecoms here, not home-office users. All data, cdr's, logs etc should be kept safely. Otherwise we're in deep legal trouble..


Top
 Profile  
 
 Post subject:
PostPosted: Fri Feb 09, 2007 9:04 pm 
Offline

Joined: Thu Oct 19, 2006 9:56 am
Posts: 300
Location: Athens, Greece
I back off this feature.

The reason is: I *don't* want the web-user to be able to dump the db. I see that as a security threat.
You can adjust a cronjob for the pg_dump, with a separate user and the pass in ~/.pgpass . But don't do that for apache, and *never* for user-supplied backup paths!


Top
 Profile  
 
 Post subject: Backups
PostPosted: Fri Feb 09, 2007 9:18 pm 
Offline

Joined: Tue Nov 21, 2006 7:01 pm
Posts: 19
I'm not familiar with the risk you are referring to ("Every user in the system has the right to read out the cmdline, and therefore the password"). If you could elaborate on how this is a risk I would appreciate it. Otherwise I'll take your word for it and look at alternatives.

I agree with you that trusting all local postgres users is a bad idea. However, my server is firewalled and locked down very tightly and there ARE no other users accessing it other than public http. Still, I never open up pg_hba to more than is necessary.

How about a cron job running as root dumping the db daily or weekly, and using rsync (w/ssh) to move it to another server? Then you could use logrotate on the other server to automatically keep X generations of backups. What do you think of this idea?

I suppose the other way is to figure out why setting the PGPASSWORD env var prior to issuing the pg_dump command does not work as Areski intended.

Anyone else want to comment on a good (and simple) backup strategy for A2Billing?


Top
 Profile  
 
 Post subject:
PostPosted: Fri Feb 09, 2007 9:32 pm 
Offline

Joined: Thu Oct 19, 2006 9:56 am
Posts: 300
Location: Athens, Greece
1. Just anybody running anything on your server could have the ability to issue shell commands and then read the cmdline. (I'm not sure about the security of env vars, either). Which means, that, once they issue a 'ps -ef' at your system, they have your password!
If you just trust all local users, is more secure: because the password will remain secret.
2. pg_dump was intentionally designed to not take the password like that.
3. the apache user is the most exposed one. Just any vulnerablity at a web application could let them also penetrate in a2billing.
4. Your idea about the cronjob is what I meant. That is the best one. I would also encrypt the db file before sending it. Naming the backups after their date, is also easy and will let you have a history (in case data gets damaged).
5. Note that apache still has access to a2billing whatsoever. *all* your webapps running there have to be secure, otherwise you're compromizing the call data[1].

[1] in most countries it is a crime to publish call data. It is not just any business data.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Feb 09, 2007 9:46 pm 
Offline

Joined: Thu Aug 10, 2006 10:47 pm
Posts: 145
Location: LA,CA,USA
xrg wrote:
1. Just anybody running anything on your server could have the ability to issue shell commands and then read the cmdline. (I'm not sure about the security of env vars, either). Which means, that, once they issue a 'ps -ef' at your system, they have your password!
If you just trust all local users, is more secure: because the password will remain secret.
2. pg_dump was intentionally designed to not take the password like that.
3. the apache user is the most exposed one. Just any vulnerablity at a web application could let them also penetrate in a2billing.
4. Your idea about the cronjob is what I meant. That is the best one. I would also encrypt the db file before sending it. Naming the backups after their date, is also easy and will let you have a history (in case data gets damaged).
5. Note that apache still has access to a2billing whatsoever. *all* your webapps running there have to be secure, otherwise you're compromizing the call data[1].

[1] in most countries it is a crime to publish call data. It is not just any business data.


Wow good one....ALL very valid points :!: Unfortunately.....i think this post will go WAAAAY over the heads of most users here haha....


Top
 Profile  
 
 Post subject:
PostPosted: Tue Feb 13, 2007 10:47 am 
Offline

Joined: Tue Jun 20, 2006 3:23 pm
Posts: 153
Hi Please,

I would recommend not to change any codes. This backup process working fine.

Just follow the installation - how it is described in a2b.

And for Backup - make some changes in a2billing.conf

if you are using mysql - then comment out psql. And if you are using psql then comment out mysql.


; configuration for backup and restore in mysql
[backup]

; Path to store backup of database
backup_path = /tmp

; path for gzip
gzip_exe=/bin/gzip

; path for gunzip
gunzip_exe=/bin/gunzip

; path for mysqldump
mysqldump=/usr/bin/mysqldump

; path for pg_dump - below was enabled
;pg_dump=/usr/bin/pg_dump

; path for mysql
mysql=/usr/bin/mysql

;path for psql - below was enabled
;psql=/usr/bin/psql


Top
 Profile  
 
 Post subject:
PostPosted: Tue Feb 20, 2007 12:22 am 
Offline

Joined: Tue Jun 20, 2006 3:23 pm
Posts: 153
ohh!

To save the Database - works great.


but Some problem happened with user account! so I needed to restore the database. But restore didnt work by admin interface!


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 8 posts ] 
Predictive Dialer


All times are UTC


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group