I wanted to change the backup to a different disk. I mounted the disk to /mnt2 on centos and when I navigate to Admin > Backups > Backup Daily > Edit backup-daily Backup, I see an option Server Path For Backup. I tried the following two things.
I entered the mount directory /mnt2 and hit run now. The background job fails with the following error in logs.
An error occurred while performing a backup: Backup directory provided
in configuration: '/mnt2' cannot be created or is not a directory.
I also tried creating a tmp2 directory on local drive and entered /tmp2 and hit run now. The background job fails with the same error as above.
Note 1:
I restarted the docker container just to see if it's not picking up file system changes in real time. That did not work.
Note 2:
There is a browse button next to Sever Path for Backup and I dont see /mnt2 or /tmp2 directories I created. I couldnot find anything useful in the documentation either.
How do I change the backup directory for artifactory?
The setup is artifactory with docker.
For artifactory docker instance, a volume needs to be specified so it maps to the local folder, say, /opt/artifactory/.
In my case, /var/opt/jfrog/artifactory(docker) is mapped to /opt/artifactory(local)
I am supposed to create a folder here -- /opt/artifactory/backup_mount. Give read and write access for 1039 user and group. It shows up in artifactory UI as /var/opt/jfrog/artifactory/backup_mount.
Note:
If you create a directory, it shows up without any docker restart.
If you create a mount, restart docker so the mount is recognized.
Related
I have setup a Google Compute Engine (GCE) instance and I want to mount a Google Cloud Bucket to it. Basically, I have uploaded my data to Google Cloud and I want to make it available for use in the R Studio-server I have installed in my instance. It seems my mounting was successful, but I cannot see the data on R (or in the shell).
I want the bucket to be mounted in /home/roberto/remote. I have run chmod 777 /home/roberto/remote and then gcsfuse my-project /home/roberto/remote. I got the following output:
2023/01/28 22:49:01.004683 Start gcsfuse/0.41.12 (Go version go1.18.4) for app "" using mount point: /home/roberto/remote
2023/01/28 22:49:01.022553 Opening GCS connection...
2023/01/28 22:49:01.172583 Mounting file system "my-project"...
2023/01/28 22:49:01.176837 File system has been successfully mounted.
However, I can't see anything inside /home/roberto/remote when I run ls or when I look inside of it from R Studio-server (see image below). What should I do?
UPDATE: I had uploaded my folders to google cloud, but when I uploaded an individual file, it suddenly showed up! This makes me think the issue has something to do with implicit directories. Supposedly, if I run the same command as before with the --implicit-dirs flag that would be enough (something like this: gcsfuse --implicit-dirs my-project /home/roberto/remote). However, this is returning an error message and I am not sure how to deal with it.
Error message:
2023/01/29 01:33:15.428752 Start gcsfuse/0.41.12 (Go version go1.18.4) for app "" using mount point: /home/roberto/remote
2023/01/29 01:33:15.446696 Opening GCS connection...
2023/01/29 01:33:15.548211 Mounting file system "my-project"...
daemonize.Run: readFromProcess: sub-process: mountWithArgs: mountWithConn: Mount: mount: running /usr/bin/fusermount3: exit status 1
Try to edit the VM Cloud API access scopes of Storage to Full.
Follow the steps below:
Click/Select the VM instance
Stop the VM instance, then edit the VM instance.
Scroll down to Access scopes and select "Set access for each API"
Change the Storage from Read Only to Full.
Save and start your VM instance.
Then SSH to your VM instance and try to ls /home/roberto/remote
Other answers here could be useful depending on your issue. In my case, what solved it was indeed running the command gcsfuse --implicit-dirs my-project /home/roberto/remote. The error I was getting in the edit for my question was due to the fact that I had previously mounted the bucket and was trying to mount it again without unmounting it first (here is the official documentation on how to unmount the bucket). For more details on the importance of the --implicit-dirs flag take a look at the official documentation here. There are very similar solutions using, for instance, the /etc/fstab file. For that, take a look at this discussion in the official github page of gcsfuse.
Try running gcsfuse mount command with debug flags which will help in knowing why the mount failed.
Eg: gcsfuse --implicit-dirs --debug_fuse --debug_gcs --debug_http my-project /home/roberto/remote
I had created a Google compute engine (virtual machine) instance with RStudio Server being unaware that RStudio Server is a licensed software. Now, my trial license for RStudio has expired, and I cannot login to my R sessions anymore.
However, I had written some code which I need to recover. How do I download the files?
I have SSH-ed into my virtual machine but cannot find the relevant files or a way to download them.
I had a similar issue and I was able to recover the files by performing the following steps:
SSH to the virtual machine
Once you are in the virtual machine run the following command: cd ../rstudio-user/
Now ls there you will see the file structure you used to see in the RStudio Server interface}
Navigate using cd and ls between the folders to get to the desired file
Once you are in the desired location (where with an ls you can see the files you want to recover) run the following command: pwd
Click on the Engine and go to download file
Enter the full path of the file you want to download, it will be something like: /home/rstudio-user/FILENAME.R
Click on Download
You can do this for each of the files you want to recover.
In case you want to recover a full folder its easier to compress to a zip file and then to download it.
When I created a new .conf file inside /etc/supervisor/conf.d/ and tried to start this program it was showing some errors (fatal error) and restarting frequently by itself. Then I ran the command sudo service supervisor restart but now the supervisor also stopped and couldn't be restarted it. During solving my error the nginx server also got stuck also.
After spending a vast time I recovered it Alhamdulillah and writing the solution in the answer section.
Don't trust the solution entirely for your problem. Your problem may belong to another issues as well.
Sometime Supervisor can show the below horrible error when you restart the
service (by the command sudo service supervisor restart):
unix:///var/run/supervisor.sock refused connection
Try to diagnosis the problem with the command supervisord. You can also run journalctl -xe.
Problems and Solutions:
When you write a new .conf file to inside the /etc/supervisor/conf.d directory which contains some statements that are generating error.
Like, you write some statements that will run a script. That script contains some statements that runsGunicorn to deploy a python web apps. In the script you wrote a statement to bind an unix socket. But the mentioned directory where the unix socket will be created doesn't give permission to create the .sock file there. This can lead the permission error.
The demo gunicorn command is below:
SOCKFILE = /home/shamim/python_project/another_directroy/gunicorn.sock
gunicorn ${DJANGO_WSGI_MODULE}:application \
--name $NAME \
--bind=unix:$SOCKFILE
If the another_directory doesn't give the permission to create a .sock file inside it then an error can be occurred. So give it enough permission to create something here from outside. Or, Bind IP and port instead unix socket (like 127.0.0.1:ANY_PORT). Be sure first the port is not used by another application.
Sometimes the error can be occurred if any directory path is used inside .conf file but actually that directory doesn't exist at all.
Now run the command supervisord.
If the error persists after fixing the above issues and now shows a error like -
another program is already listening on a port that one of our HTTP servers is configured to use
then run the below command to fix this issue:
sudo unlink /var/run/supervisor.sock
If the command above does not work you should check run unlink the file at /tmp/supervisor.sock
Keep in mind that the nginx server can also show some errors and fail to
restart (or start) if any .conf file contains some statement where a socket
is used but actually the socket file doesn't exist or doesn't have enough permission to be executed.
Example: If you write the below code in any nginx file config:
upstream surveyapp_payment_stripe {
server unix:/home/shamim/python_project/another_directroy/gunicorn.sock fail_timeout=0 weight=5 max_fails=3;
}
If the above socket doesn't exist or not have enough permission then some error may be occurred.
Nginx can also show error if any directory path is used here but not exists at all. To run nginx at this time quickly just delete the .conf file or edit it's extension (make another another extension type other than .conf).
Hopefully this explanation will help someone in future.
I have a Google Compute Engine VM instance with a Asterisk Server running on it. I get this message when I try to run sudo:
sudo: parse error in /etc/sudoers near line 21
sudo: no valid sudoers sources found, quitting
sudo: unable to initialize policy plugin
Is there a password for root so I can try to change it there? Any suggestions on this?
It looks like you have manually edited the /etc/sudoers file so while you would normally have sudo access, due to the parse error, you won't be able to do this directly.
Here's how to fix this situation.
1. Save the current boot disk
go to to the instance view in Developers Console
find your VM instance and click on its name; you should now be looking at a URL such as
https://console.cloud.google.com/project/[PROJECT]/compute/instancesDetail/zones/[ZONE]/instances/[VM-NAME]
stop the instance
detach the boot disk from the instance
2. Fix the /etc/sudoers on the boot disk
create a new VM instance with its own boot disk; you should have sudo access here
attach the disk saved above as a separate persistent disk
mount the disk you just attached
fix the /etc/sudoers file on the disk
unmount the second disk
detach the second disk from the VM
delete the new VM instance (let it delete its boot disk, you won't need it)
3. Restore the original VM instance
re-attach the boot disk to the original VM
restart the original VM with its original boot disk, with fixed config
How to avoid this in the future
Always use the command visudo rather just any text editor directly to edit the /etc/sudoers file which will validate the contents of the file prior to saving it.
I ran into this issue as well and had the same issue Nakilon was reporting when trying the gcloud workaround.
What we ended up doing was configure a startup script that removed the broken sudoers file.
So in your metadata put something like:
#/bin/sh
rm "/etc/sudoers.d/broken-config-file"
echo "ok" > /tmp/ok.log
https://cloud.google.com/compute/docs/startupscript
As you probably figured out this requires the /etc/sudoers file to be fixed. As nobody has root access to the instance, you will not be able to do this from inside the instance.
The best way to solve this is to edit the disk from another instance. The basic steps to do this are:
Take a snapshot of your disk as a backup (!)
Shutdown your instance, taking care not to delete the boot disk.
Start a new "debugger" instance from one of the stock GCE images.
Attach the old boot disk to the new instance.
In the debugger instance, mount the disk.
In the debugger instance, fix the sudoers file on the mounted disk.
In the debugger instance, unmount the disk
Shutdown the debugger instance.
Create a new instance with the same specs as your original instance using the fixed disk as the boot disk.
The new disk will then have the fixed sudoers file.
Since i bumped into this issue too, if you have another instance or any place where you can run with gcloud privileges, you can run:
gcloud compute --project "<project id>" ssh --zone "europe-west1-b" "<servername>"
I ran this on a server which had gcloud as root, so you login to the other box as root too! Then fix your issue. (if you don't have a box, just spin a micro up with the correct gcloud privileges) saves the hassle of disk stuff etc.
As mentioned in above comments, I am getting the same error like below in gcp VM.
sudo: parse error in /etc/sudoers near line 21
sudo: no valid sudoers sources found, quitting
sudo: unable to initialize policy plugin
To solve this
I have ssh to another vm and become root then I ran gcloud ssh command to our main vm (where you are getting the sudo error.)
gcloud compute --project "<project id>" ssh --zone "europe-west1-b "<servername>"
And BOOM!, now are login as root in the VM.
Now you can access/change the /etc/sudoers file accordingly.
I found this hack better than recreating vm/disks.
Hope this helps to someone!
It is possible to connect to a VM as root from your developers console Google Cloud Shell. Make sure the VM is running, start the shell and use this command:
gcloud compute ssh root#<instance-name> --zone <zone> [--project <project-id>]
where instance-name is found in the Compute Engine VM Instances screen. project-id is optional but required if you are connecting to an instance in a different project from the project where you started the shell.
You can then fix this and other issues that may prevent you from using sudo.
I got a Permission denied error when trying to ssh to the problem instance via gcloud. Using a startup script as mentioned above by #Jorick works. Instructions for it are here. You will have to stop and restart the VM instance for the startup script to get executed. I modified the script slightly:
rm -f /etc/sudoers.d/google_sudoers >& /tmp/startup.log
After the restart, launch an SSH session from the cloud console and check that you are able to view the file contents (with sudo more /etc/sudoers.d/google_sudoers for example). If that works your problem has been solved.
I teach high school computer science using Scala and I've managed to set up an Artifactory repo so that when my students download dependencies, we're doing most of our downloading inside the lab, rather than over the internet.
However, all our home folders are on a network drive and the terminals the students use don't have their own hard disks, so it seems silly to have dozens of copies of the same dependencies. Unfortunately, even with an Artifactory repo, SBT/Ivy copies all the artifacts into each user's ~/.ivy2/cache directory.
I've heard that, if I set up a shared filesystem repo then the artifacts won't be copied. What I can't figure out is how to export all the artifacts that Artifactory has cached for me in a format that would be recognized as a filesystem repo. (Exporting normally puts each remote repo in a separate folder that I suppose I'd have to somehow unify, but I'm not exactly sure how to do that. If that's the easiest thing to do, please explain how carefully.)
What I think I'd like to export is the remote-repos virtual repository, but that's not available as a choice on the Export page.
The other tricky part of this is that the same build file should be usable at home, where there is no proxy repo, so I'm relying on the fact that I can use /etc/sbt/sbtopts to override the repository resolution within the lab environment.
Change Ivy home
Define your sbt script with ${SBT_OPTS}:
exec java -Xmx1512M -XX:MaxPermSize=512M ${SBT_OPTS} -jar /etc/sbt/sbt-launch-0.13.0.jar "$#"
Then only in your network environment set SBT_OPTS as:
$ export SBT_OPTS="-Dsbt.ivy.home=/etc/sbt/repository"
The students probably need writing rights to the dir.
What you also can do is use davfs2 on Linux or "web folders" on Windows to simply mount Artifactory as a WebDAV resource (read-only). This avoids any indirection via a local file system, and keeping such a copy up to date.
Unmanaged dependency
How about a solution that will get you out of Ivy?
In your original build using managed dependency, run
> show full-classpath
This should display something like the following:
[info] List(Attributed(/home/foo/helloworld/target/scala-2.10/classes), Attributed(/home/foo/.ivy2/cache/com.eed3si9n/treehugger_2.10/jars/treehugger_2.10-0.3.0.jar), Attributed(/foo/.sbt/0.13.0/boot/scala-2.10.2/lib/scala-library.jar), Attributed(/home/foo/.ivy2/cache/com.github.scopt/scopt_2.10/jars/scopt_2.10-3.0.0.jar))
Create a directory named /shared/project1/lib or something and copy all the above jars in there, except for scala-library.jar.
Next, make a copy of your build and replace libraryDependency with the following:
unmanagedBase := file("/shared/project1/lib")
You should still be able to compile the code.