Re: [gentoo-user] Email clients
230729 Peter Humphrey wrote: > I've been a loyal user of KMail for many years. > Claws mail is often mentioned hereabouts and I'd like to try it, > but first I'd need to export KMail's 20-odd-year maildir history > to mbox format. I recommend a look at Mutt, which I've used very happily since c 1998 , well before Gentoo existed. I've also always used Mbox, not Maildir. Powerful, configurable, but also simple : the UNIX approach. -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-user] Email clients
On Sat, 29 Jul 2023 01:29:59 +0100 Peter Humphrey wrote: > Hello list, > > I've been a loyal user of KMail for many years. (Loyal? Masochistic > might be a better word.) It suits me exactly - or it would if it were > reliable. It isn't, though, which drives me to consider alternatives. > > Claws mail is often mentioned hereabouts, and I'd like to try it, but > first I'd need to export KMail's 20-odd-year maildir history to mbox > format. Is it enough to run KMail's Import/Export Data tool to do > this? It should be, on the face of it, but I'm suspicious (consider > me paranoid if you like). User of Claws with a local maildir here. One mail per file always felt safer to me. If you do want to keep using maildir, net-mail/dovecot provides IMAP access to ~/.maildir out of the box, and I've found this combination to be reliable. Since it's "just" local IMAP, moving data in and out can be done with most mail clients. Plus it means you're not tied to a single mail client going forward. I do miss KMail's breadth of features though. Never tried it's migration tools, sorry. Cheers, Bryan
Re: [gentoo-user] Email clients
On 2023.07.28 20:29, Peter Humphrey wrote: Hello list, I've been a loyal user of KMail for many years. (Loyal? Masochistic might be a better word.) It suits me exactly - or it would if it were reliable. It isn't, though, which drives me to consider alternatives. Claws mail is often mentioned hereabouts, and I'd like to try it, but first I'd need to export KMail's 20-odd-year maildir history to mbox format. Is it enough to run KMail's Import/Export Data tool to do this? It should be, on the face of it, but I'm suspicious (consider me paranoid if you like). I've been a happy user of Balsa for many years. It reads maildir as is, no conversion necessary. Can also use mbox and other formats, and does IMAP as well as POP3. Jack
[gentoo-user] Email clients
Hello list, I've been a loyal user of KMail for many years. (Loyal? Masochistic might be a better word.) It suits me exactly - or it would if it were reliable. It isn't, though, which drives me to consider alternatives. Claws mail is often mentioned hereabouts, and I'd like to try it, but first I'd need to export KMail's 20-odd-year maildir history to mbox format. Is it enough to run KMail's Import/Export Data tool to do this? It should be, on the face of it, but I'm suspicious (consider me paranoid if you like). -- Regards, Peter.
RE: [gentoo-user] Simple installation on BTRFS
>If you can run two disks and raid, that's always a good idea. SMART is >supposed to catch disk problems, but they still do die without warning. > >btrfs raid is (still) full of gotchas, as far as I know. > >Don't use anything higher than raid-1. Parity raid isn't reliable last I knew >... It's still not *officially* recognized as safe, but I have seen a number of people testing various ways of hitting it over the head that used to break it without losing their data. Big thing is that in the case of power failure you really *need* to run a scrub just in case there was an incomplete write. One will be fine, but if you allow them to stack up you will *eventually* start losing things. >> Your favoured snapshot/backup strategy? > >Manual ... probably shouldn't be. I snapshot / every friday before I do an >emerge on Saturday. /home I ought to snapshot more than I do. Note that you can use the snapshot to build your updates as binpackages and test out how they work before touching your main system. Saves on service downtime and doesn't risk breaking your main system if something goes wrong. Does maybe mean doing the upgrade twice unless you just pivot to the snapshot once it's ready. > >WATCH YOUR FREE DISK. I think it's all sorted now, but whatever you're using >it was always a good idea not to go over 90% full. For a very long time, a >combination of snapshots and a full disk would wedgie the system, such that >the only way to free up space was to reformat the entire disk! As I say, I >think it's now fixed so you can delete snapshots, but >90% ain't a good idea >anyway Mostly sorted. You can still get it wedged if you run the disk all the way up to full, but you can, at least, add another volume to give yourself workspace to straighten it out. And it only seems to happen if you're using disparate-sized disks in a RAID, which throws off its free space calculations. LMP
Re: [gentoo-user] Simple installation on BTRFS
On Friday, 28 July 2023 08:07:10 BST Wols Lists wrote: > On 27/07/2023 17:18, Michael wrote: > > Any gotchas I should be mindful of? > > If you can run two disks and raid, that's always a good idea. SMART is > supposed to catch disk problems, but they still do die without warning. Yes, esp. SSDs. > btrfs raid is (still) full of gotchas, as far as I know. > > Don't use anything higher than raid-1. Parity raid isn't reliable last I > knew ... I've read some horror stories, but I don't know if the problem was one of bad implementation/recovery, or entirely the fault of the fs. This guy did some comparisons on RAID 5 which worked OK - at least during his experiments: https://unixsheikh.com/articles/battle-testing-zfs-btrfs-and-mdadm-dm.html#btrfs-raid-5 The btrfs docs advice caution: https://btrfs.readthedocs.io/en/latest/btrfs-man5.html#raid56-status-and-recommended-practices > Make sure you know what you're getting. FS people seem to concentrate on > protecting the file system, not the data. I believe btrfs will raid-1 > the metadata without asking if it can, you need to actively ask for the > data to be raided, and that's caught people out not realising btrfs > treats data and metadata differently. (cf the ext3/4 debacle) > > > Your favoured snapshot/backup strategy? > > Manual ... probably shouldn't be. I snapshot / every friday before I do > an emerge on Saturday. /home I ought to snapshot more than I do. I'm also rather reactive and ad hoc with backups. Hence I'm now looking to implement something more systematic. > WATCH YOUR FREE DISK. I think it's all sorted now, but whatever you're > using it was always a good idea not to go over 90% full. For a very long > time, a combination of snapshots and a full disk would wedgie the > system, such that the only way to free up space was to reformat the > entire disk! As I say, I think it's now fixed so you can delete > snapshots, but >90% ain't a good idea anyway > > Cheers, > Wol I've had a /var/ partition on btrfs fill up, because I had forgotten to set up logrotate! No subvolumes or snapshots in there, so deleting some old logs allowed a full recovery with no loss of data. The problem with snapshots is they creep gradually on you as data starts to differ over time and suddenly you could find yourself out of space and potentially out of luck. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Simple installation on BTRFS
On Thursday, 27 July 2023 18:30:11 BST Neil Bothwick wrote: > On Thu, 27 Jul 2023 17:18:14 +0100, Michael wrote: > > Although I've been using btrfs for the best part of 10 years I have not > > really done justice to it, because I have neither explored nor used > > enough most of its features. I am now thinking of installing Gentoo on > > btrfs again, but this time I want to optimise the structure of btrfs > > subvolumes, to simplify snapshots and backups. > > > > I see Ubuntu and derivates install the OS root fs under btrfs subvolume > > "@" and /home under subvolume "@home". This makes storing snapshots of > > the two subvolumes under the btrfs top-volume, which remains unmounted, > > cleaner and reduces the chance of mixing up the fs you may end up in > > and operate on (live, or snapshot). > > > > I have 3 partitions for /boot(ESP), / and /home, but have not yet > > created additional partitions for general data storage and backups. > > > > What's your recommended approach and subvolume structure for the > > deployment of btrfs on Gentoo for a personal PC, if the primary > > objective is simplicity in maintenance, combined with ease of fs > > recovery? > > I too put everything on subvolumes, and set the one containing / to be > the default when mounted without a subvolid. When you say "everything", do you include temporary and virtual filesystems too (e.g. /sys, /proc/ /tmp, /run), or do you place these in hierarchically lower subvolumes so they are not backed up? Also, how do you treat /var/db and /var/cache/distfiles? How much space do you allocate for snapshots and at what point you start moving/deleting older snapshots? > > Any gotchas I should be mindful of? > > > > Your favoured snapshot/backup strategy? > > I have a script, I can share it with you if you don't criticise my > coding, that creates and destroys snapshots from cron. Based in principle > on zfs-snapshot but written from scratch. Me, criticise anyone's coding?! I couldn't code my way out of a paper bag. :-( Please send over what you have and I'll try to adjust it for my use, or at least I can see what you've written and learn from it. > > The impact of autodefrag on VM performance is noted, but then the > > example given proceeds to mount a subvolume for VM storage with > > 'autodefrag'. :-/ > > I disable COW on the subvolume containing my VM disk volumes. Yes, I've run 'chattr +C' on directories where I store VMs. > > Encryption is mentioned for VMs "... if the VM uses drive encryption, > > the whole compression strategy gets blown out of the water" but doesn't > > mention what type of encryption, or why/how this presents a problem. > > > > Given btrfs does not offer fs level encryption, what could/would work > > to encrypt a subvolume, *without* requiring an initrd, or the > > introduction of encryption becoming orthogonal with snapshots and > > backups? I am not clear on the best strategy and components to achieve > > this. I'm also concerned of introducing an additional complexity layer > > in trying to recover btrfs when/if fs corruption creeps in. > > The lack of encryption is a problem. You have to encrypt the block > device(s) containing btrfs, which means you will need an initrd. It also > means each component of a RAID is encrypted separately. so I only use > encryption on laptops. The alternative is to use ecryptfs for individual > subvolumes or directories. I have one SSD and a larger spinning disk. I have a separate partition on the SSD for /home, so I could put dm-crypt on this partition alone and afford some basic security for personal data against opportunistic theft. No RAID on this box, unless you suggest to create a RAID 1 with two partitions, in case the SSD cells go wrong on one of them? Without RAID things should be simpler with block device level encryption for / home. But, ... will this work without an initrd? The unencrypted rootfs will be mounted before /home. I am also not clear on steps I would need to follow in recovery operation scenarios and what I must have available to achieve this. It is not as simple as booting with any ol' liveUSB to try to access an unecrypted drive/ partition. I'll need dm-crypt and cryptsetup, or ecryptfs-utils and some familiarity with these tools, if I'm not reading off my exceptionally well structured notes I had the premonition to put together BEFORE the drive went south. ;-) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Simple installation on BTRFS
On Fri, 28 Jul 2023 08:07:10 +0100, Wols Lists wrote: > WATCH YOUR FREE DISK. I think it's all sorted now, but whatever you're > using it was always a good idea not to go over 90% full. For a very > long time, a combination of snapshots and a full disk would wedgie the > system, such that the only way to free up space was to reformat the > entire disk! As I say, I think it's now fixed so you can delete > snapshots, but >90% ain't a good idea anyway That's been fixed for a long time, but you can still run out of space when old metadata clogs things up. The fix is simple if a little time consuming and covered in detail in the wiki. As you say though, not filling up a filesystem is generally the best idea. -- Neil Bothwick Tact is the intelligence of the heart. pgpJj3dzdGm3S.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Simple installation on BTRFS
On 27/07/2023 17:18, Michael wrote: Although I've been using btrfs for the best part of 10 years I have not really done justice to it, because I have neither explored nor used enough most of its features. I am now thinking of installing Gentoo on btrfs again, but this time I want to optimise the structure of btrfs subvolumes, to simplify snapshots and backups. Okay, I've chosen to run ext over lvm over raid, so my only experience of btrfs is SUSE using it as default, but ... I see Ubuntu and derivates install the OS root fs under btrfs subvolume "@" and /home under subvolume "@home". This makes storing snapshots of the two subvolumes under the btrfs top-volume, which remains unmounted, cleaner and reduces the chance of mixing up the fs you may end up in and operate on (live, or snapshot). I have 3 partitions for /boot(ESP), / and /home, but have not yet created additional partitions for general data storage and backups. What's your recommended approach and subvolume structure for the deployment of btrfs on Gentoo for a personal PC, if the primary objective is simplicity in maintenance, combined with ease of fs recovery? I did investigate btrfs ... Any gotchas I should be mindful of? If you can run two disks and raid, that's always a good idea. SMART is supposed to catch disk problems, but they still do die without warning. btrfs raid is (still) full of gotchas, as far as I know. Don't use anything higher than raid-1. Parity raid isn't reliable last I knew ... Make sure you know what you're getting. FS people seem to concentrate on protecting the file system, not the data. I believe btrfs will raid-1 the metadata without asking if it can, you need to actively ask for the data to be raided, and that's caught people out not realising btrfs treats data and metadata differently. (cf the ext3/4 debacle) Your favoured snapshot/backup strategy? Manual ... probably shouldn't be. I snapshot / every friday before I do an emerge on Saturday. /home I ought to snapshot more than I do. WATCH YOUR FREE DISK. I think it's all sorted now, but whatever you're using it was always a good idea not to go over 90% full. For a very long time, a combination of snapshots and a full disk would wedgie the system, such that the only way to free up space was to reformat the entire disk! As I say, I think it's now fixed so you can delete snapshots, but >90% ain't a good idea anyway Cheers, Wol
