- luv-main - example.com

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

kvm network problem
by Russell Coker 15 May '18

15 May '18

It seems that there is some sort of race condition related to kvm on one of my servers where starting kvm virtual machines will cause networking to stop. while sleep 5 ; do ping -c4 8.8.8.8 && killall -1 qemu-system-x86_64; done To solve this I run the above shell code while starting kvms, if something goes wrong then it kills them all and networking works again. This first happened in March, so I think it was some Debian update in that time period that introduced the issue. The problem is that I don't reboot KVM servers very often so it's a little difficult to narrow the problem down. I don't know for sure that my other KVM servers don't have the issue, maybe they have just got lucky every time I booted them. Any suggestions for what to investigate? PS that's why the LUV server has had some downtime today. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/

1 0

Re: luv-main Digest, Vol 81, Issue 3
by Mike Hewitt 09 May '18

09 May '18

Nice to have a chat about git. I use git daily but probably at a low level. The post prompted me to enter 'git help init bare' . I mostly work in the relevant directory as in cd xxx ; do git stuff - like in the output of the above command. I find git great for collaboration and was heartened lat week when a pull request that I posted last October was accepted. I've had several other pull requests accepted and it is always a boost when they happen... If anyone wanted to play / test with git collaboration - so any code does not have to be serious then count me in ... Mike On 09/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 (Brian May) > > > _______________________________________________ > luv-main mailing list > luv-main(a)luv.asn.au > https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

1 0