I have configured gitlab.rb file and reconfigured gitlab server gitlab-ctl reconfigure to apply configuration changes:
I generated a gitlab backup with the following command:
gitlab-backup create
In the firts try, 6 old backups have been deleted. However, I have more backups in etc/gitlab/config_backup folder. I have made a second try with the backup creation command and it did not delete any old backup:
In etc/gitlab/config_backup folder lot of old backups still remain:
BTW, the date configuration of the server is correct:
What can I do in order to delete all the old backups? Do I need to remove them manually?
It appears your backup name is different- note how your Creating backup archive: XXXXX does not match any of your gitlab_config_XXX.tar backup names.
I would hazard that you have some other backup task that is backing up your /etc/gitlab folder (which is never backed up by gitlab-backup as you can see in your first screen capture.)
It would also help if you grabbed your gitlab_rails['backup_path'] = "/path/here" and verified your backup location which most likely is not and should not be /etc/gitlab.
I have found a similar issue and had to pass the "--delete-old-backups" parameter/argument to get the old backups to purge.
gitlab-ctl backup-etc --delete-old-backups
This wasn't required with the main "gitlab-backup create" call, just with the "gitlab-ctl backup-etc" in my case.
Related
I have to migrate our old GitLab server to another one. Therefore I tried to create a backup using the following command:
sudo gitlab-rake gitlab:backup:create SKIP=uploads,artifacts,builds
During backing up the repositores I get the following error:
Error No space left on device
rake aborted!
Backup::Error: Backup operation failed:
gzip: stdout: No space left on device
Does someone know a way to create a backup if the server doesn't have enough space left? Is there a way to exclude specific repositories for a backup so I could split it into many backups?
I just installed the newest Omnibus Gitlab in CentOS 7. I have added my public key to my account but gitlab keeps prompting me for a password every time I try to connect using ssh, like ssh git#mygitlab.com. The git home folder is /var/opt/gitlab.
Here are the various things that I've done:
I have checked that write to authorized_keys is checked in the admin area -> settings -> network
I have chmod the relevant folders and authorized_keys file. 0700 for home, 0711 for .ssh and 0600 for authorized_key file
I have deleted and re-created the authorized_keys file
I have checked various gitlab log files and nothing shows any clue
I have restarted and reconfigured using gitlab-ctl and restarted the computer
You may want to configure Fast lookup of authorized SSH keys in the database.
This should solve the problem you're facing and it won't require manual rebuild of authorized_keys file whenever someone adds or removes SSH/deploy key in GitLab.
Edit: This bug was introduced with GitLab 12.9. It was confirmed and it should be resolved with 12.9.1 patch release, which is expected to be released soon.
I have solved half of the problem although I don't know what the root cause was. I looked into this page docs.https://docs.gitlab.com/ee/administration/raketasks/maintenance.html#rebuild-authorized_keys-fileabout rebuilding authorized_keys using this command: sudo gitlab-rake gitlab:shell:setup, and gitlab rebuild the key and created authorized_keys.lock in the .ssh folder. Now, I can ssh -T git#mygitlab.com, although the user name was changed to Anonymous, now I'm facing another problem. When I try to clone or push, gitlab said the project can't be found. :( . I guess I'll have to look for it more.
EDIT: somehow by luck, I managed to solve this by creating a new user, added the ssh key for that user and run gitlab-rake gitlab:shell:setup again to make Gitlab added the public key to authorized_keys file.
What a mess in Gitlab and I see ton of issues regarding this authorized_keys and ssh from a long long time ago (5 - 6 years ago and still similar issue) and it still happens now.
I have two machines, both running on linux with centos 7.
I have installed the rsync packages on both of them and i am able to sync a directory from one machine to the other.
Right now i am doing the syncing manually, each time i want to sync i am running the next line:
rsync -r /home/stuff root#123.0.0.99/home
I was wondering if there is a way of configuring the rsync to do the syncing automatically, every some amount of time or preferably when there is a new file of sub directory in the home directory?
Thank you for your help.
Any help would be appreciated.
If you want to rsync every some amount of time you can use cronjobs which can be configured to run a specific command each amount of time and if you want to run rsync when there is an update or modification you can use lsyncd. check this article about use lsyncd
Update:
As links might get outdated, I will add this brief example (You are free to modify it with what works best for you):
First create an ssh key on the source machine and then add the public key at the ~/.ssh/authorized_keys file on the destination machine.
In the source machine update this file ~/.ssh/config with the following content:
# ~/.ssh/config
...
Host my.remote.server
identityfile ~/.ssh/id_rsa
IdentitiesOnly yes
hostname 123.0.0.99
user root
port 22
...
And configure your lsyncd with the following then restart lsyncd's service
# lsyncd.conf
...
sync {
default.rsyncssh,
source="/home/stuff",
host="my.remote.server",
targetdir="/home/stuff",
excludeFrom="/etc/lsyncd/lsyncd.exclude",
rsync = {
archive = true,
}
}
...
You can setup an hourly cron job to do this.
rsync in itself is quite efficient in that it only transfers changes.
You can find more info about cron here: cron
I have an Omnibus installation of Gitlab and by default it stores all attachments to /var/opt/gitlab/gitlab-rails/uploads.
Unfortunately the drive is pretty small and I would like to store the attachments on a different drive. Is there some configuration magic (or something else) that can make this happen.
You should be able to change your omnibus configuration (/etc/gitlab/gitlab.rb) to customize that path, as described in "Change default file locations":
user['home'] = '/gitlab-data/home'
git_data_dir '/gitlab-data/git-data'
gitlab_rails['shared_path'] = '/gitlab-data/shared'
gitlab_rails['uploads_directory'] = "/gitlab-data/uploads"
gitlab_ci['builds_directory'] = '/gitlab-data/builds'
To move the git home directory, all GitLab services must be stopped. Run gitlab-ctl stop && initctl stop gitlab-runsvdir.
Then continue with the reconfigure.
Run sudo gitlab-ctl reconfigure to start using the central location. Please be aware that if you had existing data you will need to manually copy/rsync it to these new locations and then restart GitLab.
I see several db.* files in my /home directory, and it seems they come from perforce. For example, some files are db.archmap, db.bodtext, db.change, db.changex
Are these files useful? Can I delete them? They are making my /home directory messy
You have started a server using your home directory as the Perforce server's P4ROOT folder. Those files are files that are generated from starting the server and cannot be deleted unless you want to hose your server installation. It's not clear to me how you've started the server instance, so I'll try and cover multiple bases with my answer.
If you want to start up the server under your own account, you should set the P4ROOT environment variable and point it to where you want the server to store its files. Alternatively, when you start the server, you can specify the root folder on the command line using the -r option:
p4d -r /home/mark/p4server
which would put the server's files into the directory called 'p4server' off of my home directory.
Typically it is best to run the perforce server using a user that is dedicated to running perforce. I use a user called 'perforce'. I set P4ROOT (and other variables) in that users environment. If you cannot use a separate user, it might be easier to use the -r command line option that I mentioned above.
Those files are only server files, not client files. So it is safe to delete them, but if you start the server back up it will recreate them. So you might want to uninstall the server.
Unless you are running a beta version, they have p4sandbox coming soon(maybe in the beta, I forget) which MAY create those files. I don't have a beta version, so I can't verify what new files the client may or may not create.
You can check the documentation here to see what these files do/are for.