How do I move a snap to a new server?


#1

Perhaps this is trivial, but my google-foo hasnt yet yeilded an answer: Can someone direct me to how to dump the Rocketchat snap I have on one Debian 9 linux box and move it to a different debian 9 linux box?

I’d rather not reconfigure all the settings inside the container.

thanks,
Matt


#2

The configuration files are likely in /var/snap/$SNAP_NAME/current/ or /var/snap/$SNAP_NAME/common/. It should be a simple case of:

  • stop the service on old server
  • tar the data directories
  • copy tar to new server
  • install the snap on new server
  • stop the service on new server
  • untar the backup
  • ensure the data dirs match the new snap’s version number if you didn’t use /current or /common
  • start the service on new server

#3

Daniel,

Thank you for your note - I copied the /var/snap directory from the old debian9 system to the new, preserving permissions and the directory structure.

On the destination system, I then installed snapd.

It did not find the snaps I moved… I do:

root@kahlo:/var/snap# snap list
No snaps are installed yet. Try “snap install hello-world”.
root@kahlo:/var/snap#

Heres the install trace on the new system for the package install:

root@kahlo:/var/snap# aptitude install snapd
The following NEW packages will be installed:
apparmor{a} libapparmor-perl{a}
snap-confine{a} snapd
squashfs-tools{a}
ubuntu-core-launcher{a}
0 packages upgraded, 6 newly installed, 0 to remove and 0 not upgraded.
Need to get 6,212 kB of archives. After unpacking 32.6 MB will be used.
Do you want to continue? [Y/n/?] Y
Get: 1 http://debian.osuosl.org/debian stretch/main amd64 libapparmor-perl amd64 2.11.0-3 [82.1 kB]
Get: 2 http://debian.osuosl.org/debian stretch/main amd64 apparmor amd64 2.11.0-3 [525 kB]
Get: 3 http://debian.osuosl.org/debian stretch/main amd64 snap-confine amd64 2.21-2+b1 [65.2 kB]
Get: 4 http://debian.osuosl.org/debian stretch/main amd64 ubuntu-core-launcher amd64 2.21-2+b1 [36.0 kB]
Get: 5 http://debian.osuosl.org/debian stretch/main amd64 squashfs-tools amd64 1:4.3-3+deb9u1 [124 kB]
Get: 6 http://debian.osuosl.org/debian stretch/main amd64 snapd amd64 2.21-2+b1 [5,380 kB]
Fetched 6,212 kB in 4s (1,409 kB/s)
Preconfiguring packages …
Selecting previously unselected package libapparmor-perl.
(Reading database … 157036 files and directories currently installed.)
Preparing to unpack …/0-libapparmor-perl_2.11.0-3_amd64.deb …
Unpacking libapparmor-perl (2.11.0-3) …
Selecting previously unselected package apparmor.
Preparing to unpack …/1-apparmor_2.11.0-3_amd64.deb …
Unpacking apparmor (2.11.0-3) …
Selecting previously unselected package snap-confine.
Preparing to unpack …/2-snap-confine_2.21-2+b1_amd64.deb …
Unpacking snap-confine (2.21-2+b1) …
Selecting previously unselected package ubuntu-core-launcher.
Preparing to unpack …/3-ubuntu-core-launcher_2.21-2+b1_amd64.deb …
Unpacking ubuntu-core-launcher (2.21-2+b1) …
Selecting previously unselected package squashfs-tools.
Preparing to unpack …/4-squashfs-tools_1%3a4.3-3+deb9u1_amd64.deb …
Unpacking squashfs-tools (1:4.3-3+deb9u1) …
Selecting previously unselected package snapd.
Preparing to unpack …/5-snapd_2.21-2+b1_amd64.deb …
Unpacking snapd (2.21-2+b1) …
Setting up squashfs-tools (1:4.3-3+deb9u1) …
Processing triggers for systemd (232-25+deb9u1) …
Processing triggers for man-db (2.7.6.1-2) …
Setting up libapparmor-perl (2.11.0-3) …
Setting up apparmor (2.11.0-3) …
Created symlink /etc/systemd/system/sysinit.target.wants/apparmor.service → /lib/systemd/system/apparmor.service.
update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
diff: /var/lib/apparmor/profiles/.apparmor.md5sums: No such file or directory
Setting up snap-confine (2.21-2+b1) …
Setting up ubuntu-core-launcher (2.21-2+b1) …
Setting up snapd (2.21-2+b1) …
Created symlink /etc/systemd/system/multi-user.target.wants/snapd.autoimport.service → /lib/systemd/system/snapd.autoimport.service.
Created symlink /etc/systemd/system/timers.target.wants/snapd.refresh.timer → /lib/systemd/system/snapd.refresh.timer.
Created symlink /etc/systemd/system/sockets.target.wants/snapd.socket → /lib/systemd/system/snapd.socket.
Created symlink /etc/systemd/system/multi-user.target.wants/snapd.service → /lib/systemd/system/snapd.service.
Processing triggers for systemd (232-25+deb9u1) …

root@kahlo:/var/snap#

any other suggestions?

thanks,

Matt


#4

You didn’t move the snaps, you moved the data. Moving the snaps is likely to be a perilous job which should not be attempted.

On the final system install the snaps with snap install that you have on your old system and then copy the data into the correct place. Do not just unpack over the /var/snap directory blindly because you likely have different versions of snaps on the new system compared to the old system!

i.e. copy the data from your tarball’s my-snap-name/$highest_number/ directory into /var/snap/my-snap-name/current/, where the destination here is a symlink so it will always point to the active version on your system.


#5

Maybe a way to help combat version differences might be to do a snap refresh manually prior to bringing the data over? Just a thought. Might have to watch which channel each package was pulled from though.


#6

thanks for the replies!

ok - so let me get this straight…

on the source system:

  1. get the snap as up to date as possible (snap refresh?)
  2. stop snaps and snapd
  3. tar up the /var/snap directory

On the dest system: ( that has zero snaps and no snapd installed at all)

  1. Install snapd
  2. install the same named snap here (rocketchat)
  3. shut down snaps and snapd
  4. move the unconfigured, just-installed rocketchat snap out of the way
    (rename directory to /var/snap.hold)
  5. copy the tarball from the source system in to the place I just renamed
    the snap in #4
  6. Start snapd
  7. pray it sees / starts the snap I moved rather than the unconfigured one
    I installed and moved out of the way to /var/snap.hold

Does that sound rightish?

-Matt