Copied Site web interface not working

Troubleshooting
,
1

**CMK version: 2.0.0.p35
**OS version: Ubuntu 20.04

Error message: The requested URL was not found on this server.

I am in the process of upgrading Check_mk and Ubuntu OS. I copied my site for testing the upgrade.
sudo omd cp monitoring lab

The copy completed and the new site is running
Doing ‘status’ on site lab:
rrdcached: running
npcd: running
nagios: running
apache: running
redis: running
crontab: running

Overall state: running

I know the site is running because I am getting notifications from “lab”

However I cannot access the copied “lab” site web interface. The original site is working fine.

Where do I look to fix the “lab” web interface?

Thanks,

Todd

2

You might have encountered a possible bug in omd cp we are investigating. If it does not work, please use omd backup together with omd restore for now.

I know the documentation on doing a release upgrade is a bit fragmentary, but we are working on it. Today we added this draft on the procedure, German only for now, maybe Google Translate can be helpful…

Edit: This is not perfect, but works quite well.

3

In 2.0.0 omd mv and cp were not working fully. This was fixed in 2.1.0

Best option would be not to use omd cp in your 2.0.0 scenario. Rather create a backup of your site. Create a new site with the same version and then load the backup into it and play around with that site

1 Like
4

There in lies the reason I was making a copy. The backup is not working.

I get following error when I run the backup for my primary site.

2023-04-25 08:03:37 Verifying backup consistency
2023-04-25 08:03:40 Cleaning up previously completed backup
An exception occured:
Traceback (most recent call last):
  File "/omd/sites/monitoring/bin/mkbackup", line 668, in mode_backup
    do_backup(opts)
  File "/omd/sites/monitoring/bin/mkbackup", line 698, in do_backup
    complete_backup()
  File "/omd/sites/monitoring/bin/mkbackup", line 1345, in complete_backup
    shutil.rmtree(job_backup_path_complete())
  File "/omd/sites/monitoring/lib/python3.8/shutil.py", line 718, in rmtree
    _rmtree_safe_fd(fd, path, onerror)
  File "/omd/sites/monitoring/lib/python3.8/shutil.py", line 675, in _rmtree_safe_fd
    onerror(os.unlink, fullname, sys.exc_info())
  File "/omd/sites/monitoring/lib/python3.8/shutil.py", line 673, in _rmtree_safe_fd
    os.unlink(entry.name, dir_fd=topfd)
PermissionError: [Errno 13] Permission denied: 'mkbackup.info'

I created a new clean site and the backups completed for the new site.

And thanks for the docs on the upgrade. They are different than the ones I found here and was using.

Todd

5

@mschlenker shared with you upgrading docs for 2.1 to 2.2 - they will likely not fully apply to your scenario.

It is likely easier to fix the backup (by removing them manually as the cleanup doesnt work). Put them somewhere else though before :slight_smile:

The more tedious way would be to do the adaptations which have been added in 2.1. omd cp doesnt know anything about the checkmk site it is moving. Therefore it is not renaming configs etc properly. Thats why parts of your copy work and others not. There is a werk which describes this

6

I was able to complete the backup after removing the files and creating a new backup job - Thank you.

At this stage is the upgrade path provided here the best option, or is there another method that would be better? There seem to be two options, in-place upgrade or create a new server use a backup. Not sure which is better but my inclination is to try the in-place.

Todd

7

Both options are valid. For details on each path, follow the guide Mathias shared. While at the moment still in german only, lt goes into detail for both paths and mathias has added a lot of context/guidance on what is the better option based for different setups

1 Like
8

In this case the document covers all three branches that are maintained, but we started the work in 2.2.0. As with everything relevant for migration to newer Checkmk versions this will eventually be picked (with minor changes) to 2.1.0 and 2.0.0.

9

Yeah, I always thought we already had something in 2.1.0/2.0.0 on that, but i guess we didnt. So great to see that topic covered now. Thanks Mathias!

10

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed. Contact an admin if you think this should be re-opened.