- luv-main - luv.asn.au

How to find out if LSB 3.2 is installed in Ubuntu
by Andrew Greig 21 May '18

21 May '18

Hi All, I was a very happy RPMer but now I am on the other side before, I could enter #rpm -q lsb and get a result how do I make that sort of query in Ubuntu, please I need to install some drivers for an Epson XP 6000 and it depends on Linux Standard Base 3.2 Andrew Greig

2 2

Re: Biting the bullet - RAID
by Russell Coker 21 May '18

21 May '18

On Sunday, 20 May 2018 2:01:14 PM AEST Craig Sanders via luv-main wrote: > > In the morning I will install the 2 new 2Tb HDDs , and load the DVD to > > launch myself into unfamiliar territory, so when I get to the partition > > stage of the process I will have 1 x 1Tb HDD for the system and /home and > > the 2 x 2Tb drives for the RAID. > > Is there any reason why you want your OS on a single separate drive with no > RAID? Some people think that it's only worth using RAID for things that you can't lose. But RAID also offers convenience. If your system with RAID has one disk die you would probably like it to keep running while you go to the shop to buy a new disk. > If I were you, I'd either get rid of the 1TB drive (or use it as extra > storage space for unimportant files) or replace it with a third 2TB drive > for a three-way mirror - or perhaps RAID-5 (mdadm) or RAID-Z1 (zfs) if > storage capacity is more important than speed. I expect that if he's just starting out with RAID then he doesn't even have 2TB of data to store. > One thing I very strongly recommend is that you get some practice with mdadm > or LVM or ZFS before you do anything to your system. If you have KVM or > Virtualbox installed, this is easy. If not, install & configure libvirt + > KVM and it will be easy. BTW, virt-manager is a nice GUI front-end for > KVM. https://etbe.coker.com.au/2015/08/18/btrfs-training/ A few years ago I ran a LUV training session on BTRFS and ZFS which included deliberately corrupting disks to be prepared for real life corruption. I think this is worth doing. Everyone knows that backups aren't much good unless they are tested and the same applies to data integrity features of filesystems. > A /boot filesystem isn't really necessary these days, but I like to have > one. It gives me a standard, common filesystem type (ext4) to put ISOs > (e.g. a rescue disk or gparted or clonezilla) that can be booted directly > from grub with memdisk. If you want to have a Linux software RAID-1 for the root filesystem then a separate filesystem for /boot doesn't give much benefit. If you want to use BTRFS or ZFS for root then you want a separate /boot. You can have /boot on BTRFS but that seems likely to give you more pain than you want for no apparent benefit. On Sunday, 20 May 2018 10:27:53 AM AEST Mike O'Connor via luv-main wrote: > I suggest the following. > 1. Do not use ZFS unless you have ECC ram If you use a filesystem like BTRFS or ZFS and have memory errors then it will become apparent fairly quickly so you can then restore from backups. If you use a filesystem like Ext4 and have memory errors then you can have your data become increasingly corrupt for an extended period of time before you realise it. > 2. btrfs has real issues in a number of area so unless you are very > experienced I would not use it. If you use the basic functionality and only RAID-1 (not RAID-5 or RAID-6) then it's pretty solid. I've been running my servers on BTRFS for years without problems. > So why do it this way ? > Well LVMs give a lot of options which as not available if there not > there. This site has only a very simple example but give it a read > http://tldp.org/HOWTO/LVM-HOWTO/benefitsoflvmsmall.html That document says "Joe buys a PC with an 8.4 Gigabyte disk". I just checked the MSY pricelist, the smallest disk they sell is 1TB and the smallest SSD they sell is 120G. Any document referencing 8G disks is well out of date. https://www.tldp.org/HOWTO/Large-Disk-HOWTO-4.html The above document explains the 8.4G limit. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/

3 3

Re: servers and fans (was Re: RAM sizes)
by Rohan McLeod 21 May '18

21 May '18

Craig Sanders via luv-main wrote: > On Sun, May 20, 2018 at 01:17:24AM +1000, Russell Coker wrote: > >> One of the more dedicated members of this list got a free server system from >> LUV and uses it as his personal workstation. It has something like 96G of >> RAM but makes more noise than most people want in the same building they are >> in. There's no reason why you couldn't design a system with 24 DIMM sockets >> that doesn't sound like an aircraft taking off, but most people who want so >> much RAM have a soundproofed server room. > Or they could replace the shitty server fans with high-quality low noise fans. Or for $50 - $100; they could just replace the "shitty server fans" , with a proprietary water-cooler; - removing both the noise and the possibility that the clunky aluminium heat sink, loosens from the CPU eg http://www.msy.com.au/453-water-cooling- regards Rohan McLeod

4 6

Re: Biting the bullet - RAID
by Craig Sanders 21 May '18

21 May '18

On Mon, May 21, 2018 at 12:16:18AM +1000, Russell Coker wrote: > One recent thing I've done is to fork the "mon" monitoring system and > significantly improve a lot of the monitoring scripts. [...] /proc/mdstat > doesn't have the UUID of the RAID array, so checking by UUID would add some > overhead to the process. Would that be a useful feature? probably, sounds useful but I'm not using mon at the moment. BTW, I mostly use blkid when I need to find out a UUID or LABEL. Very parseable output format, and you can use '-o' and '-s' to get only the field(s) you want. e.g. # blkid -o value -s UUID /dev/md0 833b973d-500a-40af-833c-22f40ebae75b or # blkid -s TYPE -s UUID /dev/nvme1n1p3: UUID="b0483380-ca6f-abb3-aeeb-94793439a630" TYPE="linux_raid_member" /dev/nvme1n1p4: UUID="3da01c47-78ea-4959-9fdd-49c5b3b8bb3c" TYPE="swap" /dev/nvme1n1p5: UUID="1278363117254169428" TYPE="zfs_member" /dev/nvme0n1p3: UUID="b0483380-ca6f-abb3-aeeb-94793439a630" TYPE="linux_raid_member" /dev/nvme0n1p4: UUID="990a9dbf-0679-4b94-8af9-ba961bb2fb0a" TYPE="swap" /dev/nvme0n1p5: UUID="1278363117254169428" TYPE="zfs_member" /dev/md0: UUID="833b973d-500a-40af-833c-22f40ebae75b" TYPE="ext4" lsblk is also useful, but I find blkid's output easier to use in shell scripts. craig -- craig sanders <cas(a)taz.net.au>

1 0

Biting the bullet - RAID
by Andrew Greig 20 May '18

20 May '18

Hi All, So the time has come when I have backed up all my data, cleaned out the /home directory, and in the morning I should expect that all of my data in Dropbox has finished synching. i have downloaded and tested the Ubuntu 18.04 LTS and burned it to DVD. In the morning I will install the 2 new 2Tb HDDs , and load the DVD to launch myself into unfamiliar territory, so when I get to the partition stage of the process I will have 1 x 1Tb HDD for the system and /home and the 2 x 2Tb drives for the RAID. What should I do about partitioning? Should I use hard partitions say, 20Gb for the /root, should I use a /boot partition or just use the MBR? Is mdadm a part of this process or does it get involved later ? ZFS for the pair of drives? I am hoping that this will go very smoothly and quickly, leaving me the rest of the day for populating the RAID disks with data. One more thing, I have found OpenSuse a really poor distro for video, in my early days (Mandrake and Mandriva) really spoiled me because the Power Pack release ensured that everything was working. But Linux has really come a long way in AV and for Suse to have issues with Codecs is just a little tired. Do I have to jump through hoops in Ubuntu to watch an MP4 or a Matroska video? May thanks Andrew Greig

9 34

Re: Biting the bullet - RAID
by Russell Coker 20 May '18

20 May '18

On Sunday, 20 May 2018 4:49:24 PM AEST Craig Sanders via luv-main wrote: > Labels aren't ugly but they're subject to human error, fallibility, and > laziness - it's easy to think that "root" is a great label for the root fs > if it doesn't occur to you at the time that you might one day want to put > that drive into another system (that may also have such intuitively obvious > filesystem labelling) LVM VG names are also subject to this. Connect 2 disks with LVM and the same VG name to a system and you get lots of interesting things happen. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/

1 0

Re: Biting the bullet - RAID
by Rick Moen 20 May '18

20 May '18

Quoting Craig Sanders (cas(a)taz.net.au) > I haven't cited a "variety of ills" because there aren't a variety of them. > There's just one: assuming that drive device names will remain the same on > every reboot, every time, forever. That one ill can result in a multitude of > problems, but they all stem from that one error. And they're all avoidable by > simply not making that mistake. All I can say is that your description of my 26 years' experience in using Linux in precisely that way as a 'mistake' (recipe for problems) has found no match in my particular experience, under the constraints described. > A SHA1 or MD5 or whatever hash is slightly shorter but no more human-readable > than current UUIDs. Looks substantially shorter, to me. Also, I'll guesstimate, too, that a substantially shorter hash than that would yield reasonable uniqueness. > I don't need to tell myself the bleeding obvious. Again, 26 years' experience, as detailed, says otherwise. > Good for you. You're lucky. I _very_ much doubt that. In fact, I smell a crock (a gross exaggeration). > However, assuming that your experience is universal is always a bad > idea. This I carefully did _not_ do. Please read more carefully. > Giving out advice based on that presumed universality is even worse. And this I _very_ much did not do. Please read a great deal more carefully. > You mean by NOT having lots of drives in my machines? I mean by being more careful about matching of drives to machines. Works for Me.[tm[

2 1

Re: Biting the bullet - RAID
by Rick Moen 20 May '18

20 May '18

Quoting Craig Sanders (cas(a)taz.net.au) > i.e. label collisions are not an accident, they're the inevitable result of > poor planning. Sure. > The trouble is that unless you want to use UUIDs there isn't any alternative. Well, speak for yourself. I've been using /dev/sdX (never used IDE ;-> ) on Linux since 1992, and for whatever reason never encounter the variety of ills you cite. > There's not much use to a "unique" identifier that is only "unique" some of > the time, or only unique as long as any humans involved don't do the kinds of > things that us humans are prone to doing. Personally, I'd settle (or consider settling, depending on outcomes) for a human-compatible identifier that's roughly as unique as an SHA1 hash is, or maybe even an order of magnitude or so less so. As I'm sure you know, those are not guaranteed absolutely reliable as a digest form of the things they stand for, but for all _practical_ purposes they are. For purposes of my disk identifiers, it really doesn't bother me that a few thousand other disks somewhere else on the planet might at some given time have the same identifier. As the late Adam Osbourne or Osbourne Computer used to say, 'Adequacy is sufficient.' (Hey, I'm old, and I was a member of the Homebrew Computer Club as a teenager.) > So it makes sense to give a UUID to disks/partitions/filesystems by default. You keep telling yourself that. ;-> > and then one day you'll compile the latest shiniest new kernel and discover > that the kernel devs really weren't joking when they said you can't rely on > the names to remain the same. You keep saying that. It's been 26 years. > I see it frequently. But my main file server has 8 SATA drives plugged into > an LSI SAS controller and a few more in SATA ports on the motherboard. Yeah, personally I'd carefully avoid that. > mdev already has helper scripts that create the same kind of /dev/disk/by-* > symlinks that udev does. Well, I'll not use those. ;->

1 0

basic git use
by Russell Coker 19 May '18

19 May '18

I want to have a git repository accessed via ssh. Just for me, no plans to give anyone else access. Below is the transcript of what I did, how do I solve the problem at the end of git refusing to update a checked out branch? rjc@linux:/tmp$ mkdir orig rjc@linux:/tmp$ cd orig rjc@linux:/tmp/orig$ git init Initialized empty Git repository in /tmp/orig/.git/ rjc@linux:/tmp/orig$ ls -al > file rjc@linux:/tmp/orig$ git add file rjc@linux:/tmp/orig$ git commit file [...] 1 file changed, 5 insertions(+) create mode 100644 file rjc@linux:/tmp/orig$ cd .. rjc@linux:/tmp$ mkdir copy rjc@linux:/tmp$ cd copy rjc@linux:/tmp/copy$ git init Initialized empty Git repository in /tmp/copy/.git/ rjc@linux:/tmp/copy$ git pull localhost:/tmp/orig remote: Counting objects: 3, done. [...] >From localhost:/tmp/orig * branch HEAD -> FETCH_HEAD rjc@linux:/tmp/copy$ git push localhost:/tmp/orig fatal: The current branch master has no upstream branch. To push the current branch and set the remote as upstream, use git push --set-upstream localhost:/tmp/orig master rjc@linux:/tmp/copy$ git push --set-upstream localhost:/tmp/orig master rjc@linux:/tmp/copy$ ls -al > file2 rjc@linux:/tmp/copy$ git push -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/

7 16

git pull push
by Mike Hewitt 17 May '18

17 May '18

hello there , I do the pull and push from loads of places - to test configurations on different distros etc - sometimes several times a day (or even hour). maybe I am non understanding something but it goes like this : 1. change something in a repo 2. git add then git commit then git push 3. Over on the other distro I do a git pull and get all my changes Mike On 17/05/18 12:00, luv-main-request(a)luv.asn.au wrote: > Send luv-main mailing list submissions to > luv-main(a)luv.asn.au > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main > or, via email, send a message with subject or body 'help' to > luv-main-request(a)luv.asn.au > > You can reach the person managing the list at > luv-main-owner(a)luv.asn.au > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of luv-main digest..." > > > Today's Topics: > > 1. Re: basic git use (Russell Coker) > 2. Re: basic git use (Andrew Pam) > > > _______________________________________________ > luv-main mailing list > luv-main(a)luv.asn.au > https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

1 0