helpstoreBackup - Support: sr #110508, Use of uninitialized value...

 
 

sr #110508: Use of uninitialized value $ENV{"USER"}

Submitted by:  None
Submitted on:  Fri 11 Jun 2021 08:30:47 AM UTC  
 
Category:  None Priority:  5 - Normal
Severity:  3 - Normal Status:  None
Privacy:  Public Assigned to:  None
Originator Email:  -email is unavailable- Open/Closed:  Open
Operating System:  None

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Fri 11 Jun 2021 01:17:03 PM UTC, comment #4: 

Hello,

of course it's ok with the next version. By no means did I want to hurry you to anything. Putting an extra line in my wrapper script wasn't that hard. ;)

I also get the problem with /tmp/storeBackup.lock on a multi-user-system. Which is a use case I didn't think about, since on my servers the users don't get shell-access. But it's interesting that even SUSE has interest in this project.

Greetings

Lookbehind

Anonymous
Fri 11 Jun 2021 12:44:35 PM UTC, comment #3: 

It's better to do it that way, of course. I will adjust this in the next version (I hope this is ok!?).

The request for the change came from SUSE, because the old variant of writing the lock file to /tmp/storeBackup.lock allows a denial of service attack (and doesn't allow e.g. two users to backup at the same time).

The problem with the cron jobs probably slipped through my fingers.

Heinz-Josef Claes <hjclaes>
Project Administrator
Fri 11 Jun 2021 10:12:42 AM UTC, comment #2: 

Hello,

of course it's easy to just set the variable beforehand. But is it a good idea to rely on a variable, that in a lot of cases (I bet I'm not the only one running this as a cronjob) is not present? The next thing that probably also isn't set is $HOME.

I'm not a perl developer, so I can't speak to the quality of the following, but a quick google search [1] revealed a solution using:

```
my $username = getpwuid( $< );
```

Which seams pretty handy as it can also reveal the home directory [2]:

```
getpwuid($id)
This function returns the password file entry for the user ID $id.

#!/usr/bin/perl

# get user info
($name, $pass, $uid, $gid, $quota, $comment, $gcos, $dir, $shell, $expire) = getpwuid(1000);
```

By the way, was there a specific reason to move the default lockFile location? Of the top of my head I can't see a problem with the old default being in /tmp, which should be usable by everybody. But I'm probably missing something.

I guess I found the reason why my backups still work. I explicitly set the lockFile location in the config-files. So the location is not dependent on the actual outcome of the evaluation of the env-var.

Greetings

Lookbehind

1) https://stackoverflow.com/questions/1378221/how-can-i-get-name-of-the-user-executing-my-perl-script
2) https://www.techrepublic.com/article/obtain-user-group-and-process-information-in-perl/

Anonymous
Fri 11 Jun 2021 09:33:46 AM UTC, comment #1: 

Hi,

the environment variable "USER" is needed to set the lock file differently for root and other users. (Writing it to /var/lock for non-root users causes permissions problems in some distributions).
If the variable is not set (this happens mainly in cron jobs) please export it e.g. simply with
export USER=root
before calling storeBackup.

Greetings,
Heinz-Josef

Heinz-Josef Claes <hjclaes>
Project Administrator
Fri 11 Jun 2021 08:30:47 AM UTC, original submission:  

Hello,

since I upgraded to 3.5.1 two days ago, I get the following error on my clients:

Use of uninitialized value $ENV{"USER"} in string eq at /usr/local/bin/storeBackup.pl line 136.

I also get a very similar error on the server:

Use of uninitialized value $ENV{"USER"} in string eq at /usr/local/bin/storeBackupUpdateBackup.pl line 104.

The server is running Debian 10, the clients are Debian 10 and 11, Ubuntu 18.04 and 20.04, Raspbian 10 and Linux Mint 19. Clients do there backups to an isolated pool with lateLinks and the server then does the merge and update part. I can provide a sample config-file (they are all basically the same apart from the series name) if that helps. But I think this is more of a general problem.

The fun thing is: The backups still work, are complete and valid. The merging and update also works, even though I get that error.

From what I found, this problem seams to only appear when storeBackup runs as a cronjob. The crontab looks like this:

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# m h dom mon dow user command
/15 7-23    *  *  root  /usr/bin/nice -n 10 /usr/local/bin/storeBackupWrapper.sh

The wrapper script does quite a lot of stuff before the actual backup begins, but nothing that is user specific or messes with environment variables. In the end it just calls:

/usr/local/bin/storeBackup.pl -f $conffile

Other things the wrapper script does:
- Check if there has been a successful backup in the last N hours (skip if so)
- Check if the last backup was successful (rerun if not)
- Check if storeBackup is already running (abort if so)
- Check for availability of the server
- Check for updated config files

I need to, one day, get this script in a proper git repository and proper shape to make that public I guess.

So I'm not entirely sure, this is actually a problem with storeBackup 3.5.1 or maybe just my setup. All I know is that I didn't have any errors with 3.5.

Greetings

Lookbehind

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by hjclaes (Posted a comment)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    No changes have been made to this item

    Back to the top


    Powered by Savane 3.7