Most of the sites I’ve imported over from cPanel are working well. However, I have two sites that run the exact same code and in one a Perl module that is in a directory included by usr lib (the immediate subdirectory of where the code is) works fine and on the other user, it does not. Both worked just fine over on the old server and I’ve not modified them in any way. I think file permissions look fine and just to be safe, I ran chown -R username.username * on the problematic user’s whole home directory to try to help things along, in case I was missing a permissions issue. No dice.
Any ideas on what might go wrong on an import that I might check? There’s a gremlin somewhere, but I’m pulling my hair out trying to think of where.
(The same thing happens when run from the web – the error shows up in the Apache logs – or from the shell.)
@ID10T Thankfully, there aren’t any mailboxes at all on the account. Although I need to keep that in mind. In cPanel everything was owned by the user without subaccount ownership. Obviously, it’s much better the way Virtualmin does it, but… old habits die hard.
Ha! Yeah, it does seem like that, doesn’t it. The only error I’m getting is:
Error: Can't locate object method "new" via package "SAFARI::Retrieve"
(perhaps you forgot to load "SAFARI::Retrieve"?) at
lib/SAFARI/Core.pm line 313.
SAFARI is my custom stack for content management. Each account that uses it gets a copy from a git repository. So, if everything copied over properly, two accounts on this server should run into the same errors (or none) when running it. The library is not presently centrally installed (that’s on my todo list, but there’s a long winding reason why it isn’t), so the code starts with use lib and includes the lib/ directory that has all the SAFARI libraries in it.
I was hoping maybe there was some security setting that could have gotten flagged on the account that was causing the trouble.
An interesting note: The code runs fine if I execute it as root, but not as the user on this account. It runs fine as either user or root on the other accounts on the server.
I tried that, but alas, while it fixed how I went a bit heavy handed on permissions earlier today, it didn’t do anything to resolve the error. I appreciate the pointer to that tool for future use, though!
That’s what I wondered, too. If I run perl -E 'say for @INC' for each user, it is identical. The code in question is located within lib/ in relation to the program’s working directory and it does an include lib ‘lib/‘, so hopefully it wouldn’t even matter, but it is the same across the board.
I went further adding that relative path explicitly to Perl’s includes: export PERL5LIB=/home/melanie/www/cgi-bin/safari/lib. Running that little single liner again from above shows it does get added in to @INC at that point.
Nonetheless, on “user A”, running ./safariRetrieve.fpl from bash produces a page worth of output as it should (and does this without messing with @INC), running the exact same code on “user B” produces the aforementioned error. And both worked prior to import — in fact, for User B, I just pointed the DNS back to the old server the migration was from for now until I figure out what’s wrong on the new server.
Maybe I should just try wiping and restoring that user again…
