|
From: <rs...@ba...> - 2020-07-06 14:25:25
|
> I tried both your and Anthony's suggestions without success… I should definitely wait for the reply of OVH support! Yea, I am not trying to push you, just make suggestions that might help. > Running “apt” without sudo yields the reply (my translation): > > E: Directory /var/cache/apt/archives/partial does not exist. - Acquire (13: Permission not granted) > E: Impossible to open the lock file /var/lib/dpkg/lock - open (13: Permission not granted) > E: Impossible to lock the admin directory (/var/lib/dpkg/). Do you have superuser's rights? Yea, I strongly suspect your account is not a full virtual server, but just a shared server. In that case they cannot give you root rights because you could take down the entire server including the 100 other accounts you share with ;-). Their wording is ambivalent when it comes to describing a users capabilities with the account they provide. > For Anthony : echo $PATH returned expectedly: > /usr/local/php7.3/bin:/usr/local/bin:/usr/bin:/bin > > After all, I don't need superuser's rights. OVH folks should simply activate gcc and I would be able to run it! Build systems often require many dependencies, allowing gcc and not allowing apt access is rarely useful. They probably don’t offer that option. Gcc can also eat up a lot of system resources, another reason web-providers might not want to offer the option. And if they’d “just unlock” gcc, it would be in system-space, which would require root anyways. > From a few (old) forum entries I see that "gcc" is the C compiler in OVH. > > I finally tried to upload and untar Anthony's compiled "bp". But running "bp" claims that "there is no such file" whereas trying to run "bp32" or "bp64" tells that "this binary file cannot be executed". Still, Unix rights are identical as shown below: > > -rwxr-xr-x+ 1 letivbvp users 841072 juil. 5 04:34 bp > ... > -rwxr-xr-x+ 1 letivbvp users 997260 juil. 26 2019 bp32 > -rwxr-xr-x+ 1 letivbvp users 964200 juil. 26 2019 bp64 It’s not a user rights issue, Anthony’s bp32/bp64 only run on MacOS, I think. I am not aware of a file “bp” he provided. But if he sent you a linux-compiled file it is likely from his Ubuntu 18.04 server, which might be incompatible with your Debian Jessie environment. You could try the binary I sent yesterday, the one specifically for Debian Jessie (I can send it to your private email, if you can’t find it). But I don’t understand, why it doesn’t see the file at all... > ... > let...@ss... (php/7.3/production/stable) ~/www/bolprocessor $ ./bp-ovh_ssh: ./bp: No file or directory of this type > let...@ss... (php/7.3/production/stable) ~/www/bolprocessor $ ./bp32 > -ovh_ssh: ./bp32: cannot execute binary file: Format error for exec() > let...@ss... (php/7.3/production/stable) ~/www/bolprocessor $ ./bp64 > -ovh_ssh: ./bp64: cannot execute binary file: Format error for exec() Sorry, no joy so far ;-) But as you said, it’s always the first steps that are the most thorny and frustrating. Once you have a working workflow, things will be smooth. After all Anthony’s ports based on your code are impressively widely applicable ;-) Best .r. PS: I am not sure, why you want to do your stuff on a webserver. Are you ultimately after a website on which bolprocessor can be run, or is it just because it seems to be easy to use this kind of quasi-cloud to run your builds. Because I doubt web-providers actively support this use-case, it could be pretty demanding on the server… |
