For my local backup regimen I use flexbackup to create a full backup twice a year and differential/incremental backups on a weekly/monthly basis. I then upload these to a new amazon S3 bucket for each half year (so each bucket corresponds to the a full backup plus the associated differentials and incrementals).
I then set the bucket's lifecycle to archive to glacier (cheaper offline storage) from the month after that half year has ended (reducing costs) and to delete it a year after the half ends. It used to be possible to do this via the S3 web interface but the absolute date based options seem to have been removed in favour of time since last update, which is not what I want. However the UI will still display such lifecycles if they are configured and directs you to the REST API to set them up.
I had a look around but couldn't any existing CLI tools to do this directly but I figured it must be possible with curl. A little bit of reading later I found that it was possible but it involved some faff calculating signatures etc. Luckily EricW has written Amazon S3 Authentication Tool for Curl (AKA s3curl) which automates the majority of that faff. The tool is "New BSD" licensed according to that page or Apache 2.0 license according to the included LICENSE file and code comments.
Setup
Following the included README setup ~/.s3curl
containing your id and
secret key (I called mine personal
which I then use below).
Getting the existing lifecycle
Retrieving an existing lifecycle is pretty easy. For the bucket which I used for the first half of 2014:
$ s3curl --id=personal -- --silent http://$bucket.s3.amazonaws.com/?lifecycle | xmllint --format -
<?xml version="1.0" encoding="UTF-8"?>
<LifecycleConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<Rule>
<ID>Archive and Expire</ID>
<Prefix/>
<Status>Enabled</Status>
<Transition>
<Date>2014-07-31T00:00:00.000Z</Date>
<StorageClass>GLACIER</StorageClass>
</Transition>
<Expiration>
<Date>2015-01-31T00:00:00.000Z</Date>
</Expiration>
</Rule>
</LifecycleConfiguration>
See GET Bucket Lifecycle for details of the XML.
Setting a new lifecycle
The desired configuration needs to be written to a file. For example to set the lifecycle for the bucket I'm going to use for the second half of 2014:
$ cat s3.lifecycle
<LifecycleConfiguration>
<Rule>
<ID>Archive and Expire</ID>
<Prefix/>
<Status>Enabled</Status>
<Transition>
<Date>2015-01-31T00:00:00.000Z</Date>
<StorageClass>GLACIER</StorageClass>
</Transition>
<Expiration>
<Date>2015-07-31T00:00:00.000Z</Date>
</Expiration>
</Rule>
</LifecycleConfiguration>
$ s3curl --id=personal --put s3.lifecycle --calculateContentMd5 -- http://$bucket.s3.amazonaws.com/?lifecycle
See PUT Bucket Lifecycle for details of the XML.
I've recently packaged the sunxi tools for Debian. These are a set of tools produce by the Linux Sunxi project for working with the Allwinner "sunxi" family of processors. See the package page for details. Thanks to Steve McIntyre for sponsoring the initial upload.
The most interesting component of the package are the tools for working with the Allwinner processors' FEL mode. This is a low-level processor mode which implements a simple USB protocol allowing for initial programming of the device and recovery which can be entered on boot (usually be pressing a special 'FEL button' somewhere on the device). It is thanks to FEL mode that most sunxi based devices are pretty much unbrickable.
The most common use of FEL is to boot over
USB. In the Debian package the
fel
and usb-boot
tools are named sunxi-fel
and sunxi-usb-boot
respectively but otherwise can be used in the normal way described on
the sunxi wiki pages.
One enhancement I made to the Debian version of usb-boot
is to
integrate with the u-boot packages to allow you to easily
FEL boot any sunxi platform supported by the Debian packaged version
of u-boot (currently only Cubietruck, more to come I hope). To make
this work we take advantage of Multiarch to install the
armhf version of u-boot (unless
your host is already armhf of course, in which case just install the
u-boot package):
# dpkg --add-architecture armhf
# apt-get update
# apt-get install u-boot:armhf
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
u-boot:armhf
0 upgraded, 1 newly installed, 0 to remove and 1960 not upgraded.
Need to get 0 B/546 kB of archives.
After this operation, 8,676 kB of additional disk space will be used.
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
Selecting previously unselected package u-boot:armhf.
(Reading database ... 309234 files and directories currently installed.)
Preparing to unpack .../u-boot_2014.04+dfsg1-1_armhf.deb ...
Unpacking u-boot:armhf (2014.04+dfsg1-1) ...
Setting up u-boot:armhf (2014.04+dfsg1-1) ...
With that done FEL booting a cubietruck is as simple as starting the board in FEL mode (by holding down the FEL button when powering on) and then:
# sunxi-usb-boot Cubietruck -
fel write 0x2000 /usr/lib/u-boot/Cubietruck_FEL/u-boot-spl.bin
fel exe 0x2000
fel write 0x4a000000 /usr/lib/u-boot/Cubietruck_FEL/u-boot.bin
fel write 0x41000000 /usr/share/sunxi-tools//ramboot.scr
fel exe 0x4a000000
Which should result in something like this on the Cubietruck's serial console:
U-Boot SPL 2014.04 (Jun 16 2014 - 05:31:24)
DRAM: 2048 MiB
U-Boot 2014.04 (Jun 16 2014 - 05:30:47) Allwinner Technology
CPU: Allwinner A20 (SUN7I)
DRAM: 2 GiB
MMC: SUNXI SD/MMC: 0
In: serial
Out: serial
Err: serial
SCSI: SUNXI SCSI INIT
Target spinup took 0 ms.
AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
flags: ncq stag pm led clo only pmp pio slum part ccc apst
Net: dwmac.1c50000
Hit any key to stop autoboot: 0
sun7i#
As more platforms become supported by the u-boot packages you should
be able to find them in /usr/lib/u-boot/*_FEL
.
There is one minor inconvenience which is the need to run
sunxi-usb-boot
as root in order to access the FEL USB device. This
is easily resolved by creating /etc/udev/rules.d/sunxi-fel.rules
containing either:
SUBSYSTEMS=="usb", ATTR{idVendor}=="1f3a", ATTR{idProduct}=="efe8", OWNER="myuser"
or
SUBSYSTEMS=="usb", ATTR{idVendor}=="1f3a", ATTR{idProduct}=="efe8", GROUP="mygroup"
To enable access for myuser
or mygroup
respectively. Once you have
created the rules file then to enable:
# udevadm control --reload-rules
As well as the FEL mode tools the packages also contain a FEX (de)compiler. FEX is Allwinner's own hardware description language and is used with their Android SDK kernels and the fork of that kernel maintained by the linux-sunxi project. Debian's kernels follow mainline and therefore use Device Tree.
It's taken a while but all of the pieces are finally in place to run successfully through Debian Installer on ARM64 using the Debian ARM64 port.
So I'm now running nightly builds locally and uploading them to http://www.hellion.org.uk/debian/didaily/arm64/.
If you have CACert in your CA roots then you might prefer the slightly more secure version.
Hopefully before too long I can arrange to have them building on one of the project machines and uploaded to somewhere a little more formal like people.d.o or even the regular Debian Installer dailies site. This will have to do for now though.
Warning
The arm64 port is currently hosted on Debian Ports which only supports the unstable "sid" distribution. This means that installation can be a bit of a moving target and sometimes fails to download various installer components or installation packages. Mostly it's just a case of waiting for the buildd and/or archive to catch up. You have been warned!
Installing in a Xen guest
If you are lucky enough to have access to some 64-bit ARM hardware (such as the APM X-Gene, see wiki.xen.org for setup instructions) then installing Debian as a guest is pretty straightforward.
I suppose if you had lots of time (and I do mean lots) you could also install under Xen running on the Foundation or Fast Model. I wouldn't recommend it though.
First download the installer
kernel
and
ramdisk
onto your dom0 filesystem (e.g. to /root/didaily/arm64
).
Second create a suitable guest config file such as:
name = "debian-installer"
disk = ["phy:/dev/LVM/debian,xvda,rw"]
vif = [ '' ]
memory = 512
kernel = "/root/didaily/arm64/vmlinuz"
ramdisk= "/root/didaily/arm64/initrd.gz"
extra = "console=hvc0 -- "
In this example I'm installing to a raw logical volume
/dev/LVM/debian
. You might also want to use
randmac to generate a
permanent MAC address for the Ethernet device (specified as
vif = ['mac=xx:xx:xx:xx:xx:xx']
).
Once that is done you can start the guest with:
xl create -c cfg
From here you'll be in the installer and things carry on as
usual. You'll need to manually point it to ftp.debian-ports.org
as
the mirror, or you can preseed by appending to the extra
line in the
cfg like so:
mirror/country=manual mirror/http/hostname=ftp.debian-ports.org mirror/http/directory=/debian
Apart from that there will be a warning about not knowing how to setup the bootloader but that is normal for now.
Installing in Qemu
To do this you will need a version of http://www.qemu.org
which supports qemu-system-aarch64
. The latest release doesn't yet
so I've been using
v2.1.0-rc3
(it seems upstream are now up to -rc5). Once qemu is built and
installed and the installer
kernel
and
ramdisk
have been downloaded to $DI
you can start with:
qemu-system-aarch64 -M virt -cpu cortex-a57 \
-kernel $DI/vmlinuz -initrd $DI/initrd.gz \
-append "console=ttyAMA0 -- " \
-serial stdio -nographic --monitor none \
-drive file=rootfs.qcow2,if=none,id=blk,format=qcow2 -device virtio-blk-device,drive=blk \
-net user,vlan=0 -device virtio-net-device,vlan=0
That's using a qcow2 image for the rootfs, I think I created it with something like:
qemu-img create -f qcow2 rootfs.qcow2 4G
Once started installation proceeds much like normal. As with Xen you
will need to either point it at the debian-ports archive by hand or
preseed by adding to the -append
line and the warning about no
bootloader configuration is expected.
Installing on real hardware
Someone should probably try this ;-).