Re: [CentOS] ZFS
On 9/15/2014 14:48, Andrew Holway wrote: Any comparison between ZFS and non-ZFS probably overlooks things like fully-checksummed data (not just metadata) and redundant copies. ZFS will always be slower than filesystems without these features. TANSTAAFL. Not really true. It hugely depends on your workload. For example, if you have a 20TB filesystem with 128GB of ARC (adaptive replacement cache) then ZFS will be many many times faster then ext4 assuming that the hot data is under 128GB as all reads will come from memory or a dedicated cache SSD. If however you are streaming the whole 20TB from the filesystem then the cache makes no difference and you just see the performance of the disks. The checksumming for example does not typically add a performance penalty as this calculation is done in parallel to normal disk operations. The SSD and second CPU core are not free. ZFS does more than pretty much every other mainstream filesystem, and hence needs more resources when you use its additional features. My only point is that there are people who will compare a ZFS pool with all the features turned on to a bare-bones ext4 setup, then complain that ZFS is slow. The atomistic write mechanism of ZFS can be hundreds of times faster than EXT in cases where your IO is random SYNC assuming you have a dedicated ZIL (ZFS intent log) which keeps the journal. Read up on ZFS transaction groups for more details. The ZFS is slow crowd generally doesn't care about reliable fsyncs. Hence why most PC OSes lie through their teeth when you tell them to sync a block to disk: http://queue.acm.org/detail.cfm?id=2367378 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Bare drive RAID question, was RE: *very* ugly mdadm issue [Solved, badly]
On 9/5/2014 07:18, Richard Zimmerman wrote: Until I read this thread, I've never heard of building RAIDs on bare metal drives. I'm assuming no partition table, just a disk label? I don't know what you mean by a disk label. BSD uses that term for their alternative to MBR and GPT partition tables, but I think you must mean something else. In Linux terms, we're talking about /dev/sda, rather than /dev/sda1, for example. What is the advantage of doing this? The whole idea of a RAID is that you're going to take a bunch of member disks and combine them into a larger entity. On top of *that* you may wish to create partitions, LVMs, or whatever. So the real question is, why do you believe you need to make each RAID member a *partition* on a disk, instead of just take over the entire disk? Unless you're going to do something insane like: /dev/md0 /dev/sda1 /dev/sdb1 /dev/md1 /dev/sda2 /dev/sdb2 ...you're not going to get any direct utility from composing a RAID from partitions on the RAID member drives. (Why insane? Because now any I/O to /dev/md1 interferes with I/O to /dev/md0, because you only have two head assemblies, so you've wiped out the speed advantages you get from RAID-0 or -1.) There are ancillary benefits, like the fact that a RAID element that spans the entire partition is inherently 4k-aligned. When there is a partition table taking space at the start of the first cylinder, you have to leave the rest of that cylinder unused in order to get back into 4k alignment. The only downside I saw in this thread is that when you pull such a disk out of a Linux software RAID and put it into another machine, you don't see a clear Linux partition table, so you might think it is an empty drive. But the same thing is true of a hardware RAID member, too. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Bare drive RAID question, was RE: *very* ugly mdadm issue [Solved, badly]
On 9/5/2014 08:18, Scott Robbins wrote: On Fri, Sep 05, 2014 at 08:01:05AM -0600, Warren Young wrote: I don't know what you mean by a disk label. There is another method of disk naming, I think it gained popularity between /dev/sda and UUID, that was something like LABEL=swap or LABEL=root. That's a property of the filesystem, not the disk or partition. See tune2fs/mke2fs -L. As for building on bare metal, as it stands, during installation, the RedHat way is you make, for example, a /boot, / and swap, then make the same partitions on drive 2 (for a RAID-1). The system disk must be partitioned because you need a boot loader, which means you're already going to be taking over some space on cylinder 0, so the arguments in favor of raw disks have already gone out the window. I'm only talking about data volumes here. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] *very* ugly mdadm issue
On 8/29/2014 14:26, m.r...@5-cent.us wrote: Note that we did this on *raw*, unpartitioned drives (not my idea). Nothing wrong with that, particularly with big midden volumes like this one. I added /dev/sdc to /dev/md4, and it started rebuilding. *facepalm* You forgot the primary maxim of data integrity: two is one, one is none. When you overwrote your original copy with what you thought was a clone, you reduced yourself to a single copy again. If anything is wrong with that copy, you now have two copies of the error. What you *should* have done is buy two drives, set them up as a new mirror, copy the data over to them, then pull the old /dev/sdc and put it on a shelf as an offline archive mirror. /dev/sdc has probably already given you its rated service life, so it's not like you're really saving money here. The drive has already depreciated to zero. You're probably going to spend more in terms of your time (salary + benefits) to fix this than the extra drive would have cost you, and at the end of it, you still won't have the security of that offline archive mirror. I know this isn't the answer you wanted, but it's probably the answer a lot of people *wanted* to give, but chose not to, going by the crickets. (It's either that or the 3-day holiday weekend.) I don't know how much I can help you. I have always used hardware RAID on Linux, even for simple mirrors. I don't see why it matters that your /dev/sdd partitioning is different from your /dev/sdc. When you told it to blast /dev/sdc with the contents of /dev/sdd, it should have copied the partitioning, too. Are you certain /dev/sdc is partially overwritten now? What happens if you try to mount it? If it mounts, go buy that second fresh disk, then set the mirror up correctly this time. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] *very* ugly mdadm issue
On 9/2/2014 12:05, Keith Keller wrote: On 2014-09-02, Warren Young war...@etr-usa.com wrote: On 8/29/2014 14:26, m.r...@5-cent.us wrote: Note that we did this on *raw*, unpartitioned drives (not my idea). Nothing wrong with that, particularly with big midden volumes like this one. Indeed--hardware RAID controllers don't partition their drives before creating their arrays. It also has the side benefit that you don't have to worry about 4K partition alignment. Starting with 0 means you're always aligned. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] An R rpm question
On 9/2/2014 12:37, m.r...@5-cent.us wrote: The server they want downgraded is running 4.1.0-5; ?? The latest version of R is 3.1.1: http://www.r-project.org/ Do you mean 3.1.0-5? ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Packages cmake (base) and metis (epel) conflict with each other
On 8/25/2014 15:06, Peter Wood wrote: I don't recall ever running into a conflict between packages in base and packages in epel repositories. I see it here, too. It's clearly a packaging bug, probably due to the fact that the more recent Red Hattish Linuxes use CMake 2.8+. EPEL has a cmake28 package. Installing it doesn't placate the dependency checker, but you could force the install, then link the cmake28 binary to cmake. Or, you could try it with the platform CMake, and hope 2.6 is sufficient. It may well be. CMake is fairly stable from a feature standpoint. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Port scanning from MicroSoft?
On 8/25/2014 18:18, Nathan Duehr wrote: How one could get into the VM business without KNOWING idiots would happily pay for and utilize VMs on big bandwidth to do stupid human tricks, and take appropriate precautions NOT to become part of the problem… is beyond me. Easy. 1. Most of these bots are probably zombie infections, using resources paid for by someone else. 2. These bots use CPU, memory, and bandwidth, which is how these providers make their money. The more you use, the more money they make. Wondering why they don't take measures to stop it is like wondering why Exxon hasn't started building Tesla Supercharger stations everywhere. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Some thoughts on systemd
On 7/17/2014 11:39, Keith Keller wrote: (Not suggesting that systemd actually solves this issue, only that boot time is important in some use cases.) Well, *something* is making EL7 boot a lot faster than EL6. My EL6 test VM takes almost twice as long to boot to a console login (runlevel 3) as my EL7 test VM. If you extract the BIOS and GRUB time as fixed constants, it probably *is* twice as fast. The advantages of Docker will swamp this benefit for the massive VM rollout case you mention, but for me and my little squad of test VMs, I'm happy to have the faster restarts. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS 7 in VirtualBox
On 7/10/2014 15:02, Wes James wrote: So for some reason the installer has the interface as default off. Probably security. It gives you a chance to boot the new box up and tighten things down before turning on the Ethernet port. To make it come up on first boot, go to the Configure - General tab , in the network configuration section and say Automatically connect to the network when available. You also have the option to bring up the Ethernet connection just during installation, which can be useful with DHCP in a netinstall. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] iptables question
On 6/16/2014 15:58, Chuck Campbell wrote: If they keep going through this ip block, they will still get 255 attempts at the root password and 1020 attempts at other login/password combinations before they are blocked by fail2ban. I'm glad you got your firewall problem sorted out, but I can't let this comment slide. If removing a thousand possibilities from the pool of available credentials puts your servers at significant risk, your passwords are too weak. Let's say you're using 12-character alphanumeric passwords, mixed case, no symbols, 3/4 alphabetic. That gives a search space of 3.28 x 10^21 possible passwords.[1] Knocking off 1,000 passwords on each pass means you need 3.28 x 10^18 passes to explore all options. Since there are only 3.7 x 10^9 public IPv4 addresses, total,[2] that means if every single public machine (or NAT) on the Internet were gathered into a massive zombie net, the chance of them cracking one of your passwords is 1 in a billion. My state lottery offers better odds. And we haven't even added symbols yet. But, I hear you say, fail2ban doesn't ban an IP forever. True. What it does is greatly stretch out the time between hammer blows, above that of ssh's own attack mitigation timers. Let's say you set the ban expiration time to 5 minutes. Let's also say you really annoyed someone, so they rent time on a 1 million machine zombie net, just to try and break into your server. Let's also say they focus their entire attack on a single account, rather than guess user names as well as passwords, as is common for SSH crackbots. The zombie net factor drops the 10^18 pass count magnitude above to the order of 10^12. 10^12 * 5 minutes is about 10 million years. If you start using pre-shared keys and configure sshd to accept keys only,[3] you turn lottery odds into astronomical odds. The twelve character passwords above have about 71 bits of entropy, if you pick them randomly. A generated SSH key is as close to random as you're likely to get, and it will have a *minimum* of 1,024 bits of entropy. Every bit of entropy doubles the required attack time, so you turn 10^9 into 10^ridiculous. (Well known exponent in number theory, that.) What if we're willing to settle for human time scales, rather than astronomical ones? Using the information above, I have come to the realization that if I can hold off the crackbot hordes for just another 100 years, I can stop caring about the risks, on account of the fact that I expect someone else will be taking care of my remaining CentOS 3 servers by then, and they will change the passwords shortly after handover. It turns out that 8 random lowercase letters is sufficient to buy me those 100 years. I can then go play Tetris in my centenarian dotage without a care for the security of my old Linux boxen. So, unless your passwords are weaker than 8 lowercase random letters, you're literally wasting time manually banning IPs. Let fail2ban do its job, while you go off and do something a dumb computer can't. I've used fail2ban myself, but only to cut down on log noise, not because it adds any real security. In the end, I've found that moving ssh to a nonstandard port is just as effective at reducing log noise. [1] https://www.grc.com/haystack.htm [2] http://goo.gl/7LtFvE [3] http://goo.gl/02oksG ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] iptables question
On 6/17/2014 19:35, Chuck Campbell wrote: I haven't done the load stats, but it appears to me that a hundred of these crackers hitting my machine at these rates is likely to deny my legit users some resources. So increase the fail2ban time from the default (5 minutes, as I recall) to 1 hour, or 1 day. Besides, just because the odds are against you, sometimes luck is all it takes. That sort of thinking is why governments have started to levy taxes on people who are bad at math. (i.e. lotteries) Some risks simply aren't worth worrying about. Go play with the haystack calculator I linked from my previous email. If 8 random printable ASCII characters doesn't make you sleep well at night, make it nine. Now the attack space is about 2 orders of magnitude larger. If the risk with 8 was sometime in my career, which cannot stand a single breach, the risk with 9 becomes sometime after I have shuffled off this mortal coil. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Information Week: RHEL 7 released today
On Jun 12, 2014, at 11:27 AM, Warren Young war...@etr-usa.com wrote: [*] The absolute XFS filesystem size limit is about 8 million terabytes, which requires about 500 cubic meters of the densest HDDs available today. I’ve been wondering what 500 TB looks like, so I worked it out. It requires a mere 100 x 6 TB disks for 20% redundancy. Viewed that way, 500 TB looks a little on the low side. You can get a 9U server chassis[*] with its face almost covered with 50 hot-swap 3.5 inch drive trays. That puts us only one size doubling from being able to achieve a max-size array in a single server. Even if we assume SAS drives, we’re still only about 3 doublings away from filling that 9U chassis with a 500 TB array. RHEL7 will be in production 1 level support for another 5 years, enough time for those 3 doublings. I assume we’re climbing out of the doubling doldrums brought on by the Taiwan floods by now. Even if not, we’ve got another *10* years before RHEL 7 leaves production level 3 support. Apparently Red Hat picked this number by doing similar projections, and set it fairly conservatively. What this means is that some of us will be DIYing petabyte scale arrays in a single commodity chassis by the time RHEL 8 ships. I’m not talking about high-dollar SAN or Big Iron stuff here; we’ll be making them from commodity parts you can buy off NewEgg without a special order. Wow. [*] http://goo.gl/IjSdHz ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Information Week: RHEL 7 released today
On 6/11/2014 07:11, Timothy Murphy wrote: Does XFS have any advantages over ext4 for normal users, eg with laptops? If you graph machine size -- in whatever dimension you like -- vs number deployed, I think you'd find all laptops over on the left side of the CentOS deployment curve. I'd expect that curve to be a skewed bell, with a long tail of huge servers over on the right side. ext* came up from the consumer world at the same time that XFS was coming down from the Big Iron world. The gap between them has thus been shrinking, so that as implemented in EL7, ext4 has an awful lot of overlap with XFS in terms of features and capabilities. XFS still offers a lot more upside, and is more appropriate for the server systems that CentOS will most often be used on. It is a more sensible default, being the right answer for the biggest subset of the CentOS user base. Since you're over there on the left side of the curve, you may well decide that ext4 still makes more sense for you. That said, there really isn't anything about laptop use that argues *against* using XFS. It isn't a perfect filesystem, but then, neither is ext4. I've only seen it touted for machines with enormous disks, 200TB plus. ext4 in EL7 only goes to 50 TiB, whereas XFS is effectively unlimited[*]. Red Hat will only support up to 500 TiB with XFS in EL7, but I suspect it isn't due to any XFS implementation limit, but just a more professional way for them to say Don't be silly. [*] The absolute XFS filesystem size limit is about 8 million terabytes, which requires about 500 cubic meters of the densest HDDs available today. You'd need 13 standard shipping containers (1 TEU) to transport them all, without any space for packing material. If we add 20% more disks for a reasonable level of redundancy and put them in 24-disk 4U chassis and mount those chassis in full-size racks, we need about half a soccer field of floor space -- something like ~4000 m^2 -- after accounting for walking space, network switches, redundant power, and whatnot to run it all. It's so many HDDs that you'd need four or five full-time employees in 3 shifts to respond to drive failures fast enough to keep an 8 EiB array from falling over due to insufficient redundancy. You simply wouldn't make a single XFS filesystem that big today, so QED: effectively unlimited. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Information Week: RHEL 7 released today
On 6/12/2014 12:54, Paul Heinlein wrote: On Thu, 12 Jun 2014, Jeremy Hoel wrote: This little bit here is awesome and made me laugh. Thanks! Agreed. Warren wins the Internet today. Thank you, thank you. Now go read some What if? to see how a true master plays this game. [*] https://what-if.xkcd.com/ ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Information Week: RHEL 7 released today
On 6/10/2014 14:25, Tom Bishop wrote: And the When will Centos 7 be released questions begin in 3...2...1 It's different this time. The CentOS people have had inside access to RHEL since December last year.[1] So, when will CentOS 7 be released? :) Yes, I see Jim Perrin's post today[2] that it is in the build process, but how long does that take, if nothing goes wrong, and then how long does ISO mastering and mirror seeding take? That is to say, what is the shortest possible delay? Then, how confident are those who have been doing this work that we will get through this build process without errors, based on what happened in the beta and RC stages? Ballpark guess, that's all I'm asking. This week? This month? While the leaves are still on the trees in North America? [1] http://goo.gl/VkkRCw [2] http://goo.gl/fFhz93 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Information Week: RHEL 7 released today
On 6/10/2014 15:34, John R. Dennison wrote: On Tue, Jun 10, 2014 at 03:28:55PM -0600, Warren Young wrote: It's different this time. The CentOS people have had inside access to RHEL since December last year.[1] They have the same inside access to RHEL as everyone else; namely the RHEL 7 beta and RC releases. Really? http://sdt.bz/content/article.aspx?ArticleID=68721page=1 Several CentOS core developers are now Red Hat employees, and this changes nothing? During the ~6-month RHEL 6 to CentOS 6 effort, the reason for the delay is that Red Hat surprised everyone by changing a bunch of things. Now we have people on the inside for 6 months, but everyone's still ignorant? ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Mother board recommendation
On 6/3/2014 12:26, Lists wrote: Registered/Unregistered, CAS timing, single/double/quad ranked, never mind voltages, and making sure your CPU supports it! All of those specs are listed in the motherboard manual. If you're buying your RAM from a reseller that doesn't give you the corresponding specs to match up against the mobo specs, stop buying from that vendor. There are vendors that will match up your specific motherboard with the RAM that works in it, and will exchange the RAM for the right stuff if by some tiny chance they specified the wrong stuff. (e.g. Crucial) ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Disappearing Network Manager config scripts
On 4/29/2014 13:05, Les Mikesell wrote: can you tell it that adding a USB device and picking up a dchp address is OK, but you don't want to change your default route just because dhcp offers it? Mixed DHCP and static IP configurations is a very useful but often neglected combination. [1] Every OS I've used requires some hacking around to make it work as desired. The only reason Linux is easiest of the bunch is because it has a history of letting you turn off the automation, so you can prevent it from doing undesired things. Windows is far worse than CentOS in this regard, NM or no. [2] --- [1] A machine might need to accept a random DHCP IP in 192.168.0.x to be allowed through the LAN's restrictive Internet gateway but also need to have static IP 172.16.17.1 to serve a set of Internet-disconnected boxes in that same /24 scheme. This is easy with all modern OSes if you have two NICs and two Ethernet connections back to the nearest switch. Not so easy when both purposes must be served by a single NIC. [2] http://superuser.com/q/679134/14927 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Disappearing Network Manager config scripts
On 4/29/2014 13:17, m.r...@5-cent.us wrote: I mean, this is an ENTERPRISE o/s, and that means, heavily, *servers*, and does anyone actually use wireless, or anything other than hardwired, for a server? I think you're setting up false dichotomies here. It isn't about desktop vs server, or WiFi vs wired. First, both CentOS and Ubuntu have server and desktop focused variants. RHEL7 will make this separation even clearer[1], though it seems the reason has more to do with keeping the ISOs to single layer DVD size than because they intend for the Workstation/Client and Server editions to functionally diverge. Second, as to whether there are servers that use WiFi, of course there are. Print servers, embedded systems, media servers, IP cameras... Lots of Linux servers use WiFi. Back in the days when Big Iron Unix was the biggest piece of the market, the very thing being complained about in this thread would have been touted as a great feature over inflexible desktop OSes. Multipath I/O, hot-swap disk controllers, NIC failover, etc. all happened in that world first. Is dynamic networking any different, really? [1] RHEL 7 is apparently going to come out in 4-6 separate editions. See [http://distrowatch.com/?newsid=08406 The article only talks about three of the editions, but I've also noticed mention elsewhere of Compute Node, Atomic Host, and Guest editions. I don't know if that's really 6 separate versions, or if I, too, am making distinctions where there are none. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Disappearing Network Manager config scripts
On 4/29/2014 14:02, m.r...@5-cent.us wrote: Trains stop at a train station, buses stop at a bus station Taxis stop at the train station, cars park at the bus station, busses pull up to the airport... The lines aren't as sharp as you're trying to draw them. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Disappearing Network Manager config scripts
On 4/29/2014 14:15, m.r...@5-cent.us wrote: Compute node... it automatically detects a GPU(s)? It comes with PBS/Torque installed? Fuse? Gluster? Ready to be joined to a cluster? I'd like to see what their definition of compute node is It's probably the RHEL7 version of their HPC offering: http://www.redhat.com/products/enterprise-linux/scientific-computing/ But thanks very much for the link - I didn't know that RC 7 is out this week It's just the release candidate: http://goo.gl/cM1q2h A final release date has not been publicly announced, despite the Red Hat Summit a couple of weeks ago. FWIW, I saw somewhere that those ISOs are going to disappear fairly soon. Grab them if you want to have a play before final release. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] RHEL7 beta discussions?
On 4/23/2014 12:37, Warren Young wrote: 5. Save the following as /etc/httpd/conf.d/rhel7rc.conf: VirtualHost *:80 DocumentRoot /var/www/html/rhel7rc ServerAlias rhel7rc That should be ServerName, so that Apache serves from the rhel7rc directory only if you call it as rhel7rc. With the alias alone, this can takes over all port 80 serving. (Depends on the order the *.conf files are loaded.) ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] RHEL7 beta discussions?
On 4/2/2014 07:16, Jim Perrin wrote: I have to add the DVD as a repo. Here's what I do: You shouldn't need to do this. There should be a redhat.repo file in /etc/yum.repos.d I didn't have such a thing on the RHEL7 beta VM I set up, nor on the RHEL7 RC I just set up. /etc/yum.repos.d was empty on both machines after installation, and yum repolist all reports repolist: 0. Perhaps it only appears if you attach a RHN subscription to the machine? Digimer's DVD repo method misses out on a lot of packages since the ISO files don't include the optional package set. A big chunk of these are things like -devel packages corresponding to library packages, so if you're a software developer, the DVD/ISO contents are likely to be insufficient. My method: 1. Mount the ISO or DVD on the machine, find the Packages directory, and copy it into /var/www/html/rhel7rc on one of the LAN's web servers. (Putting it on a separate web server allows the repo to have a lifetime independent of the RHEL7 test system, and also allows you to share the repo among multiple test systems.) 2. From /var/www/html/rhel7rc on the web server, say: rsync -rv rsync://ftp.redhat.com/redhat/rhel/rc/7/Server-optional/x86_64/os/Packages . This step downloads another ~2.1 GB of RPMs beyond what came on the installation DVD, merging thousands more RPMs into the set you copied from the DVD/ISO. Substitute your OS edition for Server as necessary. Ditto CPU type. 3. Create the repo: cd /var/www/html/rhel7rc createrepo . When this completes, ls /var/www/html/rhel7rc should report: Packages repodata If you skip this step or don't do it right, yum won't chase dependencies properly. 4. Create /etc/yum.repos.d/rhel7rc.repo on the RHEL7 box: [rhel7rc] name=RHEL7 RC local mirror baseurl=http://rhel7rc/ enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release rhel7rc is a CNAME or /etc/hosts alias for the web server. We need to use such an alias because the next step is: 5. Save the following as /etc/httpd/conf.d/rhel7rc.conf: VirtualHost *:80 DocumentRoot /var/www/html/rhel7rc ServerAlias rhel7rc Directory /var/www/html/rhel7rc Allow from all AllowOverride None Options +Indexes Order allow,deny /Directory /VirtualHost Then say service httpd restart. At this point, your new local mirror of RHEL7 RC should work. (If you're wondering why I took the time to write all this up, it's because I figured it out back in December when the beta came out, then forgot a bunch of details in the ~4 months it took for the RC to come out and had to rediscover a bunch of it. If nothing else, this way I'll have a reference I can dig out of my email Sent folder the next time I need to do this.) ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] RHEL7 beta discussions?
On 4/23/2014 12:57, Les Mikesell wrote: On Wed, Apr 23, 2014 at 1:37 PM, Warren Young war...@etr-usa.com wrote: Perhaps it only appears if you attach a RHN subscription to the machine? No. It has been a while but I'm pretty sure when I installed on a laptop I ended up with rhel-beta.repo I just reinstalled my RHEL7 RC test VM, and it still doesn't have any repositories configured. That repo file came from this package: yum info redhat-release-everything The corresponding package in my VM is redhat-release-server: $ rpm -ql redhat-release-server | grep -c repos 0 (The everything ISO isn't being offered for the RC, apparently.) ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Linux malware attack
On 3/25/2014 10:38, Les Mikesell wrote: On Fri, Mar 21, 2014 at 4:18 PM, m.r...@5-cent.us wrote: #5 (non-standard port) is very useful. Huh! That's the *only* rationale I've ever heard for security through obscurity that actually makes sense. It's all obscurity even if you think you can call it something else. The original term of art has gotten stretched out of its original shape. Security through obscurity originally referred only to practices intended to confer security purely through obscurity. As soon as you learn the secret, the security is gone. Security practitioners started beating security through obscurity is bad into people's heads, until now people have this knee-jerk reaction to *any* obscurity, as though obscurity is bad in and of itself. Moving Telnet to port 2323 is security through obscurity. Moving SSH to port is defense in depth, because you still have security after an attacker penetrates the obscuration layer. For another example, think about network switches. They prevent trivial snooping on your neighbor's traffic. ARP poisoning can defeat this security-through-obscurity, but that's no reason for us to all go back to dumb hubs. To the extent that it confers security at all, switched Ethernet is one layer in a good layered defense incorporating switches *and* subnets *and* VLANs *and* encrypted tunnels. Still another example: ALSR. ASLR doesn't prevent buffer overflow attacks, it just makes them a lot harder to craft. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] biosdevname
On 3/20/2014 10:33, SilverTip257 wrote: And an interface should only be detected as pXpY if it's a PCI NIC. THOUGH I've seen it already where an onboard NIC in a Lenovo desktop was detected as p5p1. Just because the MAC chip is soldered to the motherboard doesn't mean it can't be on the PCI[e] bus. As far as I know, this new NIC naming scheme doesn't actually make distinctions based on whether a card-edge connector is involved. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos 5.10, Firefox ESR 24.3.0, Rendering Failure
On 2/13/2014 20:19, Always Learning wrote: Further to my very recent concerns that ol type=a gives digits. type=a was depreciated in HTML 4.1. depreciated means to me to be of a lesser value The word in the spec is certainly deprecated. No i. Depreciated is a different word. I now discover that ol style=list-style-type:lower-alpha; also produces digits. It works here. I tested with this document: html head titleTest/title head body ol style=list-style-type:lower-alpha liHello/li liWorld/li /ol /body /html Where should a BUG report be filled ? With Centos, the provider of Firefox ESR 24.3.0, or its parent Red Hat ? The Mozilla Bugzilla: https://bugzilla.mozilla.org/ But first, be sure of your facts. I suspect Firefox isn't the problem. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Speaking of firefox...
On 2/12/2014 15:04, m...@tdiehl.org wrote: I guess it is hard to get it tested without making it the default. No need to guess. There's plenty of evidence that at a certain point, software needs to be battle tested to shake the last bugs out. Take btrfs. It's been included in shipping kernels for 5 years now, yet people keep asking ...but is it stable? Why does the question come up? Because it isn't the default filesystem. Since it isn't installed on $BIGNUM percent of all existing Linux boxes, there is room for ignorance to sprout into doubt. Firefox's PDF reader problems are certainly not all bugs, per se. PDF is a huge bag of complex features only loosely related. I can't see Mozilla even *wanting* to implement every last behavior and feature defined by Adobe, much less accomplishing it. If your document depends on an unimplemented feature of PDF, it won't render right, so you're likely to call the viewer broken, even if every feature Firefox's PDF reader /does/ implement is flawless. This isn't about Firefox and Adobe. It's about any software development team who's set themselves the task of following the taillights of another software development team, while the latter has a bigger revenue stream. It's an inferior strategy, if your goal is to win the race. Lots of examples of that: - octave vs Matlab - Libre/OpenOffice vs MS Office (document compatibility) - Wine/ReactOS vs Windows - SharpDevelop vs Visual Studio - Gimp vs Photoshop (PSD compatibility) If you're tempted to give IE vs Firefox as a counterexample, notice that I specified a bigger revenue stream. It's a necessary precondition. IE6 was leapfrogged by Firefox and Chrome because they have an independent revenue stream, while IE does not. IE also has to move around in legal leg irons that don't hobble the others. Another non-counterexample: Linux vs big iron Unix. Big iron Unix priced itself out of the segment of the market that was outgrowing the economy as a whole. Now Linux calls the dance steps. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Speaking of firefox...
On 2/11/2014 12:40, m.r...@5-cent.us wrote: Save as (why isn't there an open?) a .pdf, pull it up in acroread, and print, and everything's fine. The Firefox PDF engine is new, and PDF is complex. Hence, Firefox PDF still has problems. This is almost certainly not the right list to get this fixed. This belongs in Mozilla's bug database. If it used to work right in a past version, you need to be able to show that. If it works on other platforms, or in later versions not yet available on CentOS, you need to show that instead. If it doesn't work right in any current version of Firefox, then what you probably need to file is a request for enhancement, rather than a bug report, since Firefox probably isn't implementing every last legal behavior defined in the PDF spec. Unfortunately, you're going to have a tough time getting any developer attention on this, since PRE articles are behind a paywall. That leaves you without a ready testcase. You support computers. How does it work when someone comes up to you in your professional capacity and says when I do X, it does Y, but then refuses to let you watch while they do X? ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Speaking of firefox...
On 2/11/2014 14:27, m.r...@5-cent.us wrote: Phys Rev E, vol 77, article 030902. Do a print preview, which takes a long time, then look at the scales to the graphs on pages two and three. APS » Journals » Authorization Required Authorization Required Individual Subscribers Please log in with your APS Journals Account below. Username: Password: Forgot your username/password? Create an account ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Speaking of firefox...
On 2/11/2014 14:36, m.r...@5-cent.us wrote: for right now, that was the one that showed the problem. PRX is open-access: http://prx.aps.org/ Perhaps you can come up with a cite in that or another open-access journal, like arXiv? ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] OT hard disk geometry
On 2/7/2014 16:40, Timothy Murphy wrote: my HP SuperMicro drive-bay. SuperMicro is OEMing for HP now? In this the power connector(s) are in the same position as the empty slot above, The 4 pins next to the SATA data connector on the Seagate drive are nonstandard. Their purpose is not documented in Seagate manual: http://goo.gl/t2lncu I doubt they are some kind of secondary power connector. Far more likely are a programming header, a debug port, an auxiliary feature output (e.g. drive activity LED), a configuration jumper... (Unfortunately I cannot provide a photo at the moment, as both my Android phone and my camera are out of action.) No need. The Newegg page shows the connectors clearly: http://www.newegg.com/Product/Product.aspx?Item=N82E16822148451 If this is a standard SATA enclosure, only the two keyed edge connectors need to be used, as Kai says. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] OT hard disk geometry
On 2/6/2014 17:57, Timothy Murphy wrote: I recently purchased a 2TB WD hard drive (WD20ESRX), From where? A search on wdc.com says there is no such part number. Did you mean E*Z*RX? Can you take pictures of the drive, both sides, and post them for our perusal? ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Memory leak - how to investigate
On 2/3/2014 12:59, m.r...@5-cent.us wrote: Kwan Lowe wrote: Mem: 1361564k total, 1264324k used,97240k free, 8428k buffers That doesn't look like a lot of memory.. Possible to add another .5G or so? Ah! I missed that. Is it actually the case that your server doesn't even have 2G of RAM? That's a *real* problem. Small RAM limits with strange values like 1.3 GB are normal for VMs. Rather than give the VM more dedicated RAM, have you tried adding more swap, Jussi? Your system may be well-tuned, not I/O bound all the time swapping to disk, but that doesn't mean swap isn't useful. Modern OSes pretty much depend on having some swap space. If nothing else, it lets the OS move some little-used bits of code out of RAM, so the RAM can be used for the computer's real work. Many web stacks are RAM pigs. I don't mean they can use a lot of RAM productively, I mean they're based on inefficient or misapplied technologies that load a bunch of pointless things into RAM. Unless these things get swapped back out, they're ballooning your VM for no useful purpose. One web stack I used in the past had *GUI libraries* linked into its core executable. This, for software designed to run on headless VPSes! Another thing to look into is how many forks or threads your web stack uses. More is better for speed, up to the point where you run out of RAM, at which point your web stack slows to a crawl or dies. If each fork takes 500 MB, and you've got it set to use 3 forks, you're already running into swap space, unless there's some serious RAM sharing going on among the forks. That's another aspect of web stacks being RAM pigs: it is *possible* to make a pre-forking web stack share a lot of RAM among the forks, but it doesn't happen by itself. If you use naive defaults and naive development practices, you can end up with each fork being essentially independent copies of the whole web stack. This not only chews up RAM to no good end, it means each fork takes longer to start, which hurts site performance. Web site tuning is hard. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Memory leak - how to investigate
On 2/3/2014 13:39, Les Mikesell wrote: A new child process will share almost all memory with the parent, slowly growing as values change. The trick is to load up as much as possible in the parent before the children start forking off. If the parent does little more than initialize the web stack itself, the children don't end up sharing anything app-specific, which can end up being a huge waste of RAM. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] OT hardware question
On 1/31/2014 12:55, m.r...@5-cent.us wrote: Hmmm... that $99 each camera gets expensive, fast. Have you considered that part of the reason you're having hardware problems is that you're using $19 cameras, and expecting professional results from them? $99 for a networked PoE camera is *cheap*. When you make your presentation to the boss, bring a datasheet for any comparable Axis camera, which will be $500-1000. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] OT hardware question
On 1/31/2014 15:06, m.r...@5-cent.us wrote: That's not going to happen. The budget won't allow that much for this item. So find the person who chose that arbitrary number, and explain to them that in their ignorance, they chose a number that has no connection with reality. Ask them -- now that they know what professional equipment actually costs -- if they would like to choose a new number. We've been over this ground before, in your UPS battery thread, but I'll repeat that your salary costs are not fixed, sunk costs. The time you spend futzing with poor quality equipment is time you don't spend doing other things. If you don't include the portion of your salary with the budget, you're not doing the budget correctly. A solution that costs $1,000 in hardware but takes 1/10 your average yearly time to hand-hold is more expensive than a solution that costs $10,000 and only needs a specialist to come in and check on it once a year. If you think that's wrong, you aren't amortizing over the years the cameras are expected to last. Your time is a recurring expense; the hardware isn't. A pro-grade security camera should last many years. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [CentOS-announce] CentOS Project joins forces with Red Hat
On 1/17/2014 12:11, Les Mikesell wrote: On Fri, Jan 17, 2014 at 11:34 AM, Jim Perrin jper...@centos.org wrote: Offering free RHEL would fracture and destroy several communities, I strongly disagree with that. https://en.wikipedia.org/wiki/List_of_Linux_distributions I count 115 Debian/Ubuntu variants. (Could be off by a few, since my eyes started to cross there near the end.) 15 of those are directly under the Ubuntu umbrella; apparently they feel the need to capture at least a handful of these forks, to prevent their community from going all to pieces. That leaves a hundred non-official forks. I count only 10 RHEL derivatives, plus RHEL itself. If you throw in Fedora and its derivatives, then the total goes to 32, which only goes to prove my (and Jim's) point: the more open Fedora branch gets forked more often. Anyway, if you want a wide-open Linux, Les, you know where to get it. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [CentOS-announce] CentOS Project joins forces with Red Hat
On 1/17/2014 13:33, Les Mikesell wrote: On Fri, Jan 17, 2014 at 2:07 PM, Warren Young war...@etr-usa.com wrote: Anyway, if you want a wide-open Linux, Les, you know where to get it. Sigh..., It's complicated. I want stability and reliable security updates. But I don't like being dependent on any single entity to provide that. You want your Linux to be under control, but not controlled. Is that it? :) Someone has to have their hand on the tiller. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Advice in Time Sync
On 1/15/2014 00:56, Ku Wei Xiong wrote: How to set up timing if NTP was block by ISP? Perhaps your ISP is just blocking NTP servers outside your country. I believe the telephone number you gave in your signature terminates in Thailand, so try using th.pool.ntp.org. That domain name will resolve to an IP that is in Thailand. If my guess about your country is wrong, the same advice applies, except that you will of course need to seek out a different section of the NTP pool: http://www.pool.ntp.org/ ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] A question about 7
On 1/15/2014 05:41, mark wrote: On 01/14/14 20:17, Warren Young wrote: Now I have to remember which *PCI slot* my Ethernet card is in when I run ifconfig unless I want to dig through the full listing. What do you mean, slot? All of my servers, and our systems at home, the NIC's on the m/b. I know what you mean, but on those systems, the Ethernet MAC chip is still on the PCI[e] bus, so it still gets a slot number. If you say lspci, it's generally the second number, between the colon and dot. Fun fact: the MAC chip isn't always on a PCI[e] bus. On the Raspberry Pi, it's on the USB bus, despite the fact that it's soldered to the PCB! ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] A question about 7
On 1/13/2014 07:33, m.r...@5-cent.us wrote: is there a CentOS version of that beta? Not yet publicly available. I've heard they have something running in the development environment, but that they're still working on getting some of the RPMs to build. That's a prerequisite for generating ISOs. If not, is it likely to be a real pain, once CentOS 7 is released, to upgrade from RHEL 7 beta to CentOS 7? Anything that makes a RHEL7 - C7 transition more difficult also makes the reverse transition more difficult. In this new world of Red Hat / CentOS collaboration, that would be a Bad Thing. I'd be surprised if the transition was more difficult than just a forced upgrade of the centos-release RPM. How bad is the worst case -- reinstall the OS and rebuild the software -- anyway? By doing your initial work on the RHEL 7 beta, you learn what you need to know to quickly redo the work on CentOS 7. Reason for this: at one of my local sf clubs, I've been trying to install Evergreen, F/OSS library software, on a system, and it's a nightmare. They seem to have been building it for Ubuntu whateverthelatestanimalis. The biggest problem is, IIRC, eventhandler and memchached; oh, and it uses postgresql 9, and nothing else. PGSQL 9 was not a big deal to install, but the other stuff Even trying to build it in /usr/local is a royal mess: though I've got the dbi installed, ./configure can't find it. Post an actual error message, and someone may be able to help. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] A question about 7
On 1/14/2014 13:41, Les Mikesell wrote:
It seems like taking the list from 'rpm -qa' on a
running machine and feeding it to 'yum install '
I suspect it's not actually that simple. I think you'd need to do a
fair bit of processing on the rpm -qa list to be able to build a yum
command that will succeed. Consider the RPM provides mechanism, which
allows two different RPMs to provide the same capability under different
names. {redhat,centos}-release is this way, for example.
One of the reasons I'm playing with RHEL 7 right now is that my end
purpose is to be able to modify the documentation and scripts our system
installers will use to build new CentOS 7 systems. So, I'm already
recording all of the changes needed, partly on paper, partly in a
Subversion repository. My RHEL 7 VM is disposable.
then you need to find all of your
locally modified config files.
Whenever I'm faced with a system with unknown changes which has to be
nuked and rebuilt, I tar up /etc, /home, and *maybe* /var and/or
/usr/local.
I usually don't bother with /var, since the irreplaceable things under
/var get backed up separately: DB tables, the web tree, etc.
There are exceptions. The Bind zone files on the primary DNS server are
essentially unique, for example. (The cached version on the secondary
DNS server(s) isn't identical to the primary copy. It's stripped of
comments, the formatting is a bit different, etc.)
I scp the backup tarball off to a file server somewhere, then replace
the hard drive and start fresh. The extra HDD and disk space for the
backups are cheap insurance.
The replaced HDD can be given another mission once you're satisfied that
everything's migrated. Put it in an external USB case and use it for
the new system's off-site backup, for example.
Most of that should be under
/etc/sysconfig for an easy diff, but not everything.
Not a lot of things. I regularly modify things under
/etc/ssh/
/etc/httpd/
/etc/pki/
/etc/{init.d, rc.d}/ (via chkconfig and yum)
/etc/yum.repos.d/
/etc/samba/
Plus there's plenty at the top level that changes occasionally:
/etc/{hosts,services}
/etc/{group,passwd,shadow}
/etc/sudoers
No, I'll stand by my current practice: tar up all of /etc and /home, at
minimum.
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] A question about 7
On 1/14/2014 14:32, m.r...@5-cent.us wrote: configure can't find the interface, Were you aware that RHEL 7 now uses Consistent Network Device Naming (http://goo.gl/Z0ydDF) in more situations? It was optional in RHEL 6 (http://goo.gl/TiuTP9) but is all but enforced in RHEL 7. Everyone, drop a tear for the dead eth0. sniff We will miss you, eth0! ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] A question about 7
On 1/14/2014 16:37, Scott Robbins wrote: On Tue, Jan 14, 2014 at 02:57:20PM -0700, Warren Young wrote: Everyone, drop a tear for the dead eth0. sniff We will miss you, eth0! Haven't played much with it in CentOS. In Fedora, at present, it is a bit of pain as both biosdevname and systemd have something to do with it, making it less consistent than ever. I don't know about less consistent, but I always considered it a feature in Linux vs the BSDs or big iron Unix that I could always count on the first network interface being eth0. BSD and big iron Unix named the interface after the Ethernet driver, as if that was what was important. I get that network interfaces can move around on you, but I thought that was why they started putting the MAC address in the ifcfg-eth? scripts. What problem did that not solve, that we had to switch to this new system? Now I have to remember which *PCI slot* my Ethernet card is in when I run ifconfig unless I want to dig through the full listing. Evil shades of PR#1, begone! (Apple DOS 3.3 reference, there.) ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] A question about 7
On 1/14/2014 17:33, Ljubomir Ljubojevic wrote: If the system's BIOS does not have SMBIOS version 2.6 or higher and this data, the new naming convention will not be used. Apparently VirtualBox emulates SMBIOS, since my RHEL 7 VM uses this new scheme. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] A question about 7
On 1/14/2014 18:23, John R Pierce wrote: On 1/14/2014 5:17 PM, Warren Young wrote: I don't know about less consistent, but I always considered it a feature in Linux vs the BSDs or big iron Unix that I could always count on the first network interface being eth0. BSD and big iron Unix named the interface after the Ethernet driver, as if that was what was important. conversely, it wasn't always consistent WHICH NIC would be eth0. Had several x86 servers with dual integral nic's where eth0/eth1 were swapped relative to what RHEL/CentOS thought they were. I know the problem you mean, but doesn't the HWADDR setting in the ifcfg-ethX file fix the problem? Doesn't that force ifup eth0 to bind that file's settings to the right physical interface? In the old days, ifcfg-ethX didn't have HWADDR, so first was somewhat unpredictable, as you say. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] A question about 7
On 1/14/2014 18:34, Les Mikesell wrote: On Tue, Jan 14, 2014 at 7:17 PM, Warren Young war...@etr-usa.com wrote: Now I have to remember which *PCI slot* my Ethernet card is in when I run ifconfig unless I want to dig through the full listing. Yes, but that's something you _can_ know. How much time and resources do you need to learn the answer? Puzzle for ya: What PCI slot is the Intel e1000e MAC chip in on a Supermicro X9SCA-F motherboard? It isn't called out in the mobo manual. I just looked. (For that matter, the actual PCI slots don't have their numbers documented in the manual, either.) If you can't get lucky with Google, you're just going to have to install EL7 on it and find out. And if you can do that, why not just build it and ship it? Somehow you have to get someone to put the 4 network cables in the right NICs before anything can connect. Yes, I know that problem. We solved it here years ago by building the full system, testing it, then labeling the ports with a Sharpie. Then, later, we got really fancy and switched to a Brother label maker. Sure, it means we have to have the barebones chassis shipped here first, but as you're doubtless aware, that shipping charge is cheap next to the confusion that can happen in the field when Joe Wirepuller is asked to plug it all in, if nothing is labeled. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] A question about 7
On 1/14/2014 19:10, John R Pierce wrote: On 1/14/2014 5:55 PM, Warren Young wrote: I know the problem you mean, but doesn't the HWADDR setting in the ifcfg-ethX file fix the problem? Doesn't that force ifup eth0 to bind that file's settings to the right physical interface? In the old days, ifcfg-ethX didn't have HWADDR, so first was somewhat unpredictable, as you say. that forces it to bind to the same interface.but when you're doing a virgin install, its fairly unlikely you'll know what the MAC's are or which port it will pick to be eth0 and the setup will pick them fairly arbitrarily (bus enumeration order, typically) Yes, we've had that problem, too. Motherboard model A from Most Favored Manufacturer will put eth0 on the left, then model B replaces it, and eth0 is now on the right. We figure this out during setup, then label the ports. If we decide we really want eth0 and eth1 swapped, we swap the HWADDR lines between the ifcfg files. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] A question about 7
On 1/14/2014 19:54, Les Mikesell wrote: On Tue, Jan 14, 2014 at 8:43 PM, Stephen Harris li...@spuddy.org wrote: If you are old enough, you might remember unix versions that named disks by controller, bus, target numbers. /dev/rdsk/c0t0n0q0w0e0p1k5n8 :) It's another reason I took to Linux quickly, right along with eth0. The new process is new and therefor bad, wrong, disgusting, an abomination. But maybe... just maybe... it'll work. Maybe. If the names are relative to populated slots, maybe not. Ve shall see. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Why does 'mysql' user has /bin/bash shell?
On 1/9/2014 03:50, John Doe wrote: Default MySQL installation on CentOS sets /bin/bash as shell. I'm on a user cleanup task where I want reduce unneeded privileges to users. Its password should be locked. I just tested here on an EL6 VM that didn't have mysql-server on it before: # grep mysql /etc/shadow mysql:!!:16079:: I tried to investigate further by taking a look at the mysql-server spec file, but apparently CentOS doesn't ship with a source repo configured: $ yumdownloader --source mysql-server noise noise noise No source RPM found for mysql-server-5.1.71-1.el6.i686 I looked in CentOS-Base.repo, and don't see one I can enable. Also, connections to vault.centos.org are timing out right now, so I can't build a .repo file entry by hand. So, lacking real information, I will make a wild guess as to why this happened: someone got lazy modifying an adduser/useradd command in the mysql.spec file. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Why does 'mysql' user has /bin/bash shell?
On 1/10/2014 12:14, Reindl Harald wrote: Am 10.01.2014 20:11, schrieb Warren Young: I just tested here on an EL6 VM that didn't have mysql-server on it before: # grep mysql /etc/shadow mysql:!!:16079:: in the config file where the users shell is defined you may find more :-) grep mysql /etc/passwd You've misunderstood the point of that test. It is proof that John Doe's guess is right: the mysql user's account is locked (!!). This means that only way you can log in as mysql and thus make use of the /bin/bash setting is to first be root, then su - mysql. You can't su to mysql from a non-root account since that would require a password. That's why I guess this is a symptom of a wooly-headed change to the spec file, rather than some nefarious security breach. By the way, vault.centos.org is back. Here's what we find in the spec file: /usr/sbin/useradd -M -N -g mysql -o -r -d /var/lib/mysql -s /bin/bash \ -c MySQL Server -u 27 mysql /dev/null 21 || : ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Why does 'mysql' user has /bin/bash shell?
On 1/10/2014 13:09, Reindl Harald wrote: i know that but the question is still WHY I don't think there is a good reason. Someone made a mistake. File a bug report upstream. I've now downloaded and examined the .src.rpm for every 6.x point release plus that for 5.10, and they all do this. On skimming the changelog section of the spec file, I can't see an entry that explains why this was done. However, I might have more success if I knew the first version where this changed -- if indeed it ever did behave differently -- but I haven't found that version yet. I don't think I'm going to spend any more time looking, though, since 6.0 takes me back 3 years. This behavior has been in there for quite a long time. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Why does 'mysql' user has /bin/bash shell?
On 1/10/2014 00:40, Luigi Rosa wrote: I checked in my CentOS 6 installations. Only one (the latest) has this issue, so it could be something added/modified in the lastest months. I don't see how that can be. I've checked the spec file in the mysql.src.rpm for every 6.x point release from 6.0 through 6.5, and they *all* have this command: /usr/sbin/useradd -M -o -r -d /var/lib/mysql -s /bin/bash \ -c MySQL Server -u 27 mysql /dev/null 21 || : Actually, later versions add -N -g mysql to this, which as far as I can tell is basically pointless. It tells useradd to do exactly what it would have done by default anyway. It should have no bearing on this issue. Other installations starting from June 2013 (included) does NOT have this issue and the shell of mysql user is /sbin/nologin I have one from March 2013, and it *does* have /bin/bash as user mysql's shell. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Can we trust RedHAt encryption tools?
On 1/9/2014 15:52, m.r...@5-cent.us wrote: Robert Moskowitz wrote: Only algorithm they compromised was an RNG that got pretty strong thumbs down from the real cryptographers. They have not compromised any IETF standard; Not quite - anyone mandated to POSIX standards are effectively mandated to use the compromised algorithms, as I understand it. I think you mean FIPS 140-2, not POSIX: http://goo.gl/nLTCF8 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [CentOS-announce] CentOS Project joins forces with Red Hat
On 1/8/2014 01:14, Sorin Srbu wrote: Redhat already has Fedora as a testing ground. True, but Fedora is a bleeding-edge Linux, while CentOS is a stable Linux. Both have their place. Red Hat knows there are pieces of the Linux market it will never be able to grab significant share in. Low-end web hosting, for example. Think about it: is it better for Red Hat to spike CentOS' wheels on the hope that people will go running to RHEL, or is it better for Red Hat to make sure the CentOS project runs smoothly, so that it can keep some kind of fingerhold on these sections of the market? I know people like conspiracy theories, but do you think the pain of getting CentOS 6 out the door did Red Hat any real good? No. All that did was make Red Hat look bad. I think that's the real reason Red Hat is doing this: they want to make sure CentOS 7 launches smoothly, and are helping out the best way they can. Another good reason for Red Hat to do this is that they now have a serious answer to Ubuntu Server and Debian. Before, they were saying, Well, if you want no-cost Red Hattish Linux, you can go to *those* people over *there*. Now they can point to an official Red Hat sponsored offering. When/if those people want commercial support and such, they can use CentOS as an on-ramp to RHEL. This is a good thing. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] EL7 mirror: There is no installed groups file.
On 1/8/2014 17:00, Mark LaPierre wrote: On 01/07/2014 08:27 PM, Warren Young wrote: (I'm trying to set up a CUPS server. So yeah, X11 is a prerequisite for installing a printer now. Lovely.) How about using http://localhost:631 with lynx or some other such text based browser. I ended up writing a 2-line .xinitrc file to solve this problem: xterm exec metacity This at least lets me temporarily shell into X, as it were. This works because I've got enough of X and GNOME installed that I can get the GUI up and run programs, but the GNOME desktop proper isn't yet completely functional. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] EL7 mirror: There is no installed groups file.
I installed the RHEL 7 beta here to test while waiting for CentOS 7 to arrive. On noticing that yum didn't work, I decided to set up a local mirror. I rsync'd ftp://ftp.redhat.com/pub/redhat/rhel/beta/7/x86_64/os/Packages/ to a local web server here, then regenerated the repodata directory with createrepo. Now yum works fine, for the most part. yum search foo pulls up a plausible list of packages, yum install bar chases dependencies as expected, etc. Unfortunately, yum groupinstall isn't working, which means I have no easy way to install Gnome on my minimal EL7 installation. Apparently I need some kind of groups file to feed to createrepo --groupfile, but I don't know where to get one, or how to construct one. I've dug around on ftp.redhat.com and can't find anything that looks plausible. I've tried manually installing packages to build up this GNOME desktop, but despite installing dozens of things, startx still doesn't give me something usable. I know I could get a GNOME desktop by reinstalling the OS, but that would wipe out a lot of the local work I've done on this VM so far. The only reason I need X in the first place is that system-config-printer no longer runs in text mode. (I'm trying to set up a CUPS server. So yeah, X11 is a prerequisite for installing a printer now. Lovely.) ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] nautilus
On 12/28/2013 08:09, Eero Volotinen wrote: xhost + is very dangerous way to do that as it allows all clients to connect to display(s) Dangerous depends on your local trust model. Back when I was new to Unix -- a couple of decades ago, before widespread firewalls and such -- we tended to trust LAN users implicitly. That level of trust allowed some nice features that we've had to give up in this more hostile modern world. There once was a fun program you could run on a lab full of X Window terminals or workstations that would march an Energizer Bunny from one screen to the next, along the bottom edge of the screen. Can't do that kind of thing now, thanks to security killjoys and the bad actors that create jobs for them. Two decades later, we're contemplating encrypting everything to the Nth degree purely because there is so much mistrust -- and good reason for that mistrust -- in the world. This is an improvement? ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] And then there was one (browser)
On 12/19/2013 19:50, John R Pierce wrote: On 12/19/2013 6:43 PM, Darr247 wrote: On 20 DEC 2013 @02:06 zulu, John R Pierce wrote: how many XP systems are still in use? We have 3 XP desktops connected to the LAN in our home. that was a rhetorical question, of course I'd expect THIS email list to be skewed heavily away from the global norm. I suspect there's 100 to 1000 XP systems for every RHEL/CentOS desktop workstation on a global basis. Web site browser stats are often misused to talk about OS market share, but in this case, they're perfect. They measure exactly what we want here. One set I looked at[*] says the XP:Linux ratio is about 20:1. Others roughly confirm this. I was unable to find stats that broke the Linux portion down, which is unfortunate because it's difficult to build a browser that runs on all Linuxes out-of-the-box. Netscape used to ship an any Linux tarball, through Netscape 4. To pull that trick off, they had to include copies of *all* of the libraries it was built against except libc, even when the platform came with one or more of these libraries. The lowest-common-denominator result didn't take advantage of any platform-specific desktop features. NS4 looked and worked like CDE/Motif no matter where it ran. Chromium doesn't try to do that. They'd have to dedicate build resources -- test VMs, develoer time -- to each OS they specifically support. They'd then have to choose to either do the sort of LCD effort Netscape did, or spend development time creating workarounds for missing features on the older platforms they want to support. To hit your 100:1 number, John, EL6 would have to be 1/5 the Linux interactive desktop market. I'd be stunned if it is that high, given how popular Ubuntu and Mint are for that. I also agree that 1000:1 seems like the far edge of the probability curve. That would mean EL6 is 1/50 the total interactive desktop Linux market. It could be that bad, given that most EL6 machines are probably headless servers. [*] http://gs.statcounter.com/#desktop-os-ww-monthly-201211-201311 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] TCP port to TTY/Serial Port?
On 12/20/2013 08:13, Joseph Spenner wrote: But, I can never get the text to show up in the minicom window. You know the aphorism about hammers and nails? minicom is an awesome hammer, and here you are, presenting a problem that calls for a ratcheting box wrench. minicom is great for interactive use. When you want to do something programmatically, there's always a better way. Nux's suggestion, socat, looks like a much better choice here. I found a blog post that tells you how to create virtual serial ports connected to TCP listeners, here: http://justcheckingonall.wordpress.com/2009/06/09/howto-vsp-socat/ ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] RHEL 7 Beta is now public
On 12/17/2013 18:57, Andrew Wyatt wrote: Yes, there are many missing -devel packages. It's possible that they didn't fit on the media though, I've run into two of these myself: libedit and libgd. Both of these are living, useful libraries, without direct replacements.[*] Clearly there are RPMs shipped in the distro that require these libraries. I guess Red Hat are saying that they don't intend that you develop your *own* software against these libraries. [*] (libedit is API-compatible with readline, but most apps that use it do so in order to avoid the GPL. There are many alternatives to GD, but none are API-compatible.) ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] RHEL 7 Beta is now public
On 12/19/2013 12:16, Connie Sieh wrote: Look at lftp ftp.redhat.com:/redhat/rhel/beta/7/x86_64/os/Packages ls libedit* Thanks for the tip. The VM I'm testing RHEL 7 beta on isn't network-connected, so I guess I'm just going to have to mirror that directory. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] died again
On 12/13/2013 16:35, Michael Hennebry wrote: I note the absence of PAE for CentOS. I've read that PAE can be important. Only if you're trying to address more than 4 GB of RAM on a 32-bit system. Even then, most software doesn't take advantage of it. PAE is an old hack Intel invented in the mid 90's to ease the transition to 64-bit computing. Now that 64-bit is really, finally here, it's time to start forgetting that PAE ever existed. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] died again
On 12/15/2013 16:21, Michael Hennebry wrote: the yellow stuff looks suspicious. It's a kind of strain relief. Without that flexible glue, dropping the computer could snap those caps off at their base. Since this is the sort of thing that occasionally happens to computers in shipping, computer manufacturers try to make sure their machines can withstand a few of these sharp shocks. After all, damage in shipping is damage during the warranty period, and the shipping companies are a PITA to get insurance money out of. The darkness near the smaller yellow spot indicates my inability to position both the camera and the light the way I wanted them. That's why I mentioned reflectors and bounce cards among my photo advice. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] died again
On 12/15/2013 16:49, Michael Hennebry wrote: Looks like I'll need to see whether I still have my multimeter. That's not likely to tell you much. About the only thing I'd trust a typical DMM to tell me about a PSU is whether its rails are within voltage spec. You must do that test under load, and you need a fairly accurate DMM to get a result you can trust. If the PSU passes the voltage test, it could still be bad. The only way to tell, short of just swapping it, is to do an ESR test[*], which requires an LCR meter. (It also requires removing the PSU board from the box, which exposes you to the dangers of AC wiring and charged caps.) I don't think I've ever seen a DMM with an integrated ESR function. If such a thing does exist, the DMM would end up being pretty expensive if it gave results you could trust for this, since we're talking about measurements under 1 ohm. Decent LCR meters start at about $200 and go way up from there. Cheaper to just gamble on a PSU swap. [*] https://en.wikipedia.org/wiki/Equivalent_series_resistance ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] died again
On 12/16/2013 09:53, Michael Hennebry wrote: The one with the visible VENT and 105 printing? Vent just calls out that there is a vent on the top of the cap, which it obvious without the label. It's the scoring in the metal, which allows the top of the cap to break open in a controlled way if the pressure inside gets too high. Without the vent, a failing cap holds the pressure in until it explodes like a firecracker. The other label is actually 105℃, meaning that it's rated for a certain number of hours of use at 105℃. That means it's probably a fairly high quality cap. If you have to replace this cap, you'd want to match that temperature rating as well as the capacitance and voltage rating. You'll probably find that *all* of the caps are 105℃ rated, so they'll have that marking on them somewhere. (You think things are complicated already? Wait until you start shopping for caps!) And to the right of the pink padlocky thing. ?? Do you mean the chokes, which have yellow cores and red and orange lacquered wire? Or perhaps the dark gray cored inductors, with red wire? Or do you mean the pink resistors(?) near the board edge? To me it looks too fuzzy to tell. I'm sure that is partly the dust. Yes. You should have blown the dust out before taking the pics. It needs to be blown out regardless. VENT105 does look like it's bulging a bit. It doesn't look like it to me. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Finally.... CentOS on iMac core 2
On 11/25/2013 09:10, Warren Young wrote: Presumably RHEL7 will use grub2, Confirmed: http://goo.gl/hfwtqF ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] died again
On 12/13/2013 16:20, Michael Hennebry wrote: Any ideas on how to proceed? There may be a final screw under one of the stickers. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] RHEL 7 Beta is now public
On 12/11/2013 08:56, Karanbir Singh wrote: Within CentOS, we are going to do a CentOS7Beta1 build to match the release upsteam In the aftermath of the CentOS 6.0 trauma, I recall there being speculation that building the next major release wouldn't be as troublesome, for various reasons[*]. Did that turn out to be true? [*] a) Improved procedures, b) grand works that, done once, don't need to be done over again as long as upstream doesn't change the world again, etc. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Do I need a dedicated firewall?
On 12/11/2013 22:00, Jason T. Slack-Moehrle wrote: I have a CentOS 6.5 Server (a few TB, 32gb RAM) running some simple web stuff and Zimbra. I have 5 static IP's from Comcast. I am considering giving this server a public IP and plugging it directly into my cable modem. This box can handle everything with room for me to do more. Doing this would allow me to power down my pfSense box and additional servers by consolidating onto this single box. I have the firewall on on the server and only allowing the few ports I need. I dont run ssh on 22 What do you guys think? Have you considered moving all the public web services to a VPS, so you can use the simple firewall in your cable modem/router? You'll get much better bandwidth, and all the hardware problems are someone else's. If the machine gets broken into, it isn't a stepping stone into your private LAN. I suspect the Zimbra instance isn't public, which is good, because with its minimum RAM requirement of 2 GB, it probably isn't worth hosting publicly on your own. (Insert when I was a boy rant about 48 kB being enough here.) If you really do have to do public facing web services from your private LAN for whatever reason, though: I'd keep the separate firewall, but put it on more efficient hardware. You should be able to do this in about 5 W. At 11 cents per kWh, that's about $5 per year if it runs continually. I suspect it could actually be done in more like 2 W. (For comparison's sake, a Mac Mini idles at about 10 W, and a Raspberry Pi *peaks* at 3.5 W.) If you had to build the firewall yourself for whatever reason, there are small BSD/Linux-ready embeddable PCs you could use for this. They tend to be targeted at industrial applications and have low sales volumes, so expect to pay $200+ for them. If you're willing to go bare-bones, a Raspberry Pi, Arduino Galileo, or BeagleBone Black plus a USB-to-Ethernet adapter would do the job for under $100. If you can give up a bit of control, you can buy DD-WRT based routers off the shelf from the likes of Buffalo and Asus these days. The Buffalo unit I looked at claims to need 13 W peak, but at idle with the wireless turned off so it's a wired-only router, I'd be surprised if it didn't drop below 5 W. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] RHEL 7 Beta is now public
On 12/12/2013 09:13, James Hogarth wrote: On 12 December 2013 15:32, Warren Young war...@etr-usa.com wrote: On 12/11/2013 08:56, Karanbir Singh wrote: Within CentOS, we are going to do a CentOS7Beta1 build to match the release upsteam In the aftermath of the CentOS 6.0 trauma, I recall there being speculation that building the next major release wouldn't be as troublesome, for various reasons[*]. Did that turn out to be true? [*] a) Improved procedures, b) grand works that, done once, don't need to be done over again as long as upstream doesn't change the world again, etc. Well seeing as we haven't had a major release since then it's hard to say (although times for the point releases to come out have been markedly short)... My assumption when asking is that they had already taken enough of a look at the RH7 beta to see if Red Hat had undone the hard work of getting CentOS 6 out the door. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] died again
On 12/6/2013 16:34, Michael Hennebry wrote: There is a place for a front fan, but no fan there. It's common for cheap PC cases to have places for fans that the final PC manufacturer chooses not to populate. If you decide to put a fan there, be sure to orient it so it blows in line with the case exhaust fans. You don't want two fans blowing opposite directions on opposite sides of the case. The plastic fan shroud usually has a molded-in arrow showing the airflow direction. The plastic front of the case would have pretty much blocked it. Maybe not. Some PC case bezels have vents at the bottom edge. A common pattern is for the front PC fan to suck air in, and for the rear PC fans to blow air out. Since they're usually at opposite corners of the case, this forces air to flow through the entire case. The power supply is a sealed unit, I think you'll find that once you unscrew it from the case, you'll expose another set of screws that will let you remove the power supply's lid. The odd hole in the back of the case is designed to block access to these screws, on purpose. Don't touch anything in there unless you know your microfarads from your microhenries. Just take pics. I'm going to get my camera and take some pictures. Please do. We may well see something you didn't. Some advice, based on prior experience receiving uselessly bad pictures in the DIY electronics slice of my life: 1a. Turn on lots of lights and shine them into the case. Experiment with forced camera flash. Electronics enclosures (including PC cases) are often dark places, which means not enough photons for your camera to take a fast, sharp picture. If you can't get enough artificial light into the case, take it outside and shoot into the case with the sun over your shoulder. 1b. Bounce or diffuse as much of the light as possible. Lots of direct light is good, but if it creates blown-out flare spots or inky shadows that obscure detail, it's still no good. There are many ways to make cheap diffusers and bounce cards: old thin sheets, tin foil, poster board... Tenting a sheet over your head and the case can give a better result than a bright direct light. If your camera's flash is articulated, bounce it into the scene rather than shoot directly in. 2. Use your camera's macro function, if it has one. 10 separate pictures of 10 details is better than one overall picture where you can't even tell how many pins are on a given chip. 3. Use a tripod, if you have one. If you don't, brace the camera against something: a nearby wall, the PC case, a sandbag... A camera on a tripod set for a 30 second exposure can compensate for a *lot* of problems in area #1. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] died again
On 12/6/2013 18:00, John R Pierce wrote: On 12/6/2013 4:39 PM, Warren Young wrote: On 12/6/2013 16:34, Michael Hennebry wrote: There is a place for a front fan, but no fan there. It's common for cheap PC cases to have places for fans that the final PC manufacturer chooses not to populate. its pretty common on high end cases too. the one I have now has room for like 8 120mm fans, of which i'm using 3. The only reason I phrased it that way is that a lot of high-end machines use bespoke cases, where every fan position is populated because it was designed together as a system. Anything built from a collection of off-the-shelf parts, as DIYers and some of the smaller high-end PC makers do, can have this same sort of design mismatch. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] died again
On 12/3/2013 22:09, Michael Hennebry wrote: On Tue, 3 Dec 2013, Patrick Lists wrote: They mention high-purity isopropyl alcohol. The highest purity I've ever seen is 70%. The vast majority of the impurity in commercial grade alcohol is water. Capillary action sucks the fluid into all kinds of areas you might not expect -- like under chips -- and it stays there longer than you might guess because restricted airflow goes hand in hand with capillary action. Also, water evaporates far less readily than alcohol, increasing drying time. The rest of the impurity is dissolved solids, which gets left behind when the liquid evaporates. It also makes the fluid conductive. (Pure alcohol and pure water are *not* conductive.) Conductive liquid is obviously bad for computers, especially if it's still present when you apply power. See previous paragraph. :) Bottom line: 70% is too impure for this task. I hesitate to use even 90% for this. The last time I used 90% isopropyl on a PCB, it left behind a white haze that I had to scrub off with a dry toothbrush. I bought a box (!) of 99% isopropyl years ago: http://goo.gl/7DYP8Y It's fairly expensive to ship, but even so, it comes out cheaper than the alternatives you're likely to have locally. Figure $0.30 - $0.40 per ounce, all told. You'll probably be set for life. (Tip: Add a Menda bottle for your work table to your order, so you can keep the box safe, like in a shed or garage.) Radio Shack used to sell tape head cleaner for $1 an ounce. I'd guess it's no longer available because there's not as much call for tape head cleaning products these days. While looking for up-to-date info on Radio Shack's web site, I came across this relevant item: http://goo.gl/nLzub7 At $11 for a couple of tiny bottles, both of which you have to use together, it's another 2-3x more expensive than tape head cleaner. Plus, if you look into the MSDS, the first part is acidic, so you must need the second pass to neutralize what's left behind on the first pass. Sounds like a bad plan to me. Everclear 190 proof should also work for this. At $20 per fifth, it comes out under $1/oz, so cheaper than the RS fluids, but still more expensive than the box o' isopropyl. Some households will find it a more widely useful commodity, so there's that. :) For what it's worth, you can get even purer isopropyl alcohol intended for lab use. Prices I found online ranged from about $60-100 per liter, or $2-3/oz, shipped. 100% is possible if you synthesize it, at even higher cost. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] died again
On Dec 4, 2013, at 1:49 PM, John R Pierce pie...@hogranch.com wrote: On 12/4/2013 10:44 AM, Warren Young wrote: Bottom line: 70% is too impure for this task. Huh?!? I've cleaned numerous CPU-heatsink surfaces with 70% isopropyl, never had any problem…. I'm not saying it's impossible. An expert can ameliorate many risks through skill. That is no reason to recommend a risky process. I listed the theoretical risks in my previous post. Now for some experimental data. I filled a plastic bowl to a depth of 1 inch with the contents of a 21-year-old bottle of 70% rubbing alcohol from my medicine cabinet. (Ah, 1992…it was a good year.) I then inserted my bench DMM's probes into the bowl, spacing them approximately 1 inch apart. I read 377 kΩ. I sanity checked this measurement by moving the probes closer to each other, then farther apart, and observed that the resistance changed as expected. I poured the rubbing alcohol back into the bottle, dried the bowl with a towel, poured the contents of my electronics bench's Menda bottle -- nominally 99+% pure isopropyl alcohol -- into the bowl, then tested again. This time I read over 2 MΩ. I was expecting a higher value, or even an overload indication. I decided to refill the Menda bottle straight from the cubitainer in order to rule out impurities in the bowl, and also the natural concentration of impurities due to evaporation from the Menda bottle. This time I read over 8 MΩ. You questioned someone else's DMM in another post, so I will pre-defend mine. It's a general purpose bench meter, not a dedicated insulation tester, but it will go up to 1 GΩ, and the company that made the meter isn't the sort that publishes bogus specs. It's been a while since it was calibrated, but for 3 digit readings, I'm confident enough in its quality of design and manufacture to trust those readings anyway. I clean optical lenses with it, in the form of those eyeglass wipes you buy by the crate at Costco. I use my tee shirt. :) ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] died again
On Dec 4, 2013, at 1:22 PM, Michael Hennebry henne...@web.cs.ndsu.nodak.edu wrote: On Wed, 4 Dec 2013, Warren Young wrote: At $11 for a couple of tiny bottles, both of which you have to use together, it's another 2-3x more expensive than tape head cleaner. For me, the bottom line is how much it will cost to clean *one* CPU/heat spreader combination. Because I always have a Menda bottle full of high-purity alcohol on the electronics bench, I find many uses for it. If I had to drive to Radio Shack every ounce or so to get a refill, I would doubtless not bother for most jobs. 100% is possible if you synthesize it I'm not sure what you mean by synthesize in this context. I mean assemble the molecules from bulk quantities of their constituent elements. :) Chemical engineering. As my measurement data in the post I just sent hints, there are serious practical problems -- aside from the direct economic ones -- that restrict the utility of such high-purity alcohols. There's probably no point using it outside a cleanroom. Dust on the glassware will wreck the purity rating otherwise. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Most efficient way to create a CentOS 3 test VM
I'm about to create a new CentOS 3 VM for testing, since we still have a bunch of deployed machines running that OS. (Don't yell at me about using old OSes. These machines won't get un-deployed until they fall over dead of natural causes. Until the last one dies, we need test and build VMs around to service them.) I have the CentOS 3.9 *.iso files plus a local cache of RPMs against 3.9 that is probably incomplete relative to the vault[*]. It seems wasteful to install the last published version of the OS, then scp over my local update RPMs, freshen from those, *then* check with the vault for yet more updates. What I'm hoping for is some way to get a CentOS 3.10, being 3.9 with the vault updates directory contents merged in. Is there a straightforward way to do that, or is schlepping around folders full of RPMs actually the best way to go? [*] http://vault.centos.org/3.9/updates/i386/RPMS/ ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Finally.... CentOS on iMac core 2
On 11/25/2013 09:10, Warren Young wrote: On 11/25/2013 08:22, Wes James wrote: Oh. OK. I didn't realize CentOS wasn't using grub2. Are there any plans for CentOS to move to grub2? No. Upstream uses grub1, so CentOS uses grub1. Presumably RHEL7 will use grub2, but there's no good reason to hold your breath waiting for it. Some research confirms this. Source [1] says Fedora 16+ uses Grub2, and Source [2] says RHEL 7 will be based on Fedora 19. [1] https://en.wikipedia.org/wiki/Grub_2 [2] https://en.wikipedia.org/wiki/Rhel#cite_ref-18 Sorry, Marc. Better get used to Grub 2. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Finally.... CentOS on iMac core 2
On 11/25/2013 08:22, Wes James wrote: Oh. OK. I didn't realize CentOS wasn't using grub2. Are there any plans for CentOS to move to grub2? No. Upstream uses grub1, so CentOS uses grub1. Presumably RHEL7 will use grub2, but there's no good reason to hold your breath waiting for it. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Running MacOSX as VM under CentOS 5.10?
On 11/6/2013 12:21, Robert Heller wrote: Is it even remotely possible to run MacOSX (or Darwin) as VM under CentOS 5.10 / xen? Darwin isn't going to do you any good, since you need to test GUIs. Darwin is OS X minus everything Apple proprietary, including Cocoa, Finder, Dock... Or am I better off not even trying and just getting a MacMini or MacBook to just jack into my LAN? Yes. :) The OS X license doesn't allow installing it on non-Apple hardware, even inside a VM. This means that you *can* install OS X in a VM on a Mac, so if you need several Mac instances, you don't necessarily need several physical Macs. I don't really have the *physical* room for an iMac, unless the screen is tiny. OS X comes with VNC, configured and ready to go. You just have to check one box, in the Sharing settings pane, I believe. With a Mac Mini on WiFi, you can put it anywhere in WiFi range with a power plug. There are mounting brackets available for them, too. So, you could screw it to the wall of a utility closet, if you wanted. Being a real Unix[*] it also has ssh, and everything else you'd want for remote administration. SSH access is also off by default, but like VNC, just a checkbox away from being enabled. I believe they call it Remote Access or some such, also in the Sharing pane. I can cross-build for MS-Windows using mgwin32 OS X makes a fine VM host, by the way. There are three major VM systems for it, VMware Fusion, Parallels Desktop, and VirtualBox. All three run Windows nicely. By the way, it's MinGW, not mgwin. Minimal GNU for Windows. Minimal here refers to the fact that it was created as an alternative to Cygwin, which is much more heavyweight, but also a lot more capable. There is a complete Cygwin cross-compilation toolchain for Fedora: https://sourceforge.net/projects/fedora-cygwin/ It may be possible to port it to CentOS. Since there are MinGW cross-compilers in Cygwin, you could probably build for Windows through that. It's a lot less up front work to build on Windows, though. [*] http://unix.stackexchange.com/questions/1489/is-mac-os-x-unix ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Running MacOSX as VM under CentOS 5.10?
On 11/6/2013 17:29, Warren Young wrote: I don't really have the *physical* room for an iMac, unless the screen is tiny. OS X comes with VNC, configured and ready to go. Although OS X does make a reasonable server, it's even better as a client OS. Have you considered flipping this problem around, replacing your current desktop machine and using it to access everything *else* remotely? I wrote an article outlining the gotchas: http://unix.stackexchange.com/questions/723/726#726 If your CentOS boxes need the full power of dedicated hardware, OS X makes a fine remote terminal for them. In the previous message, I mentioned that OS X has built-in SSH and VNC servers, but it also has built-in clients. The built-in SSH client is OpenSSH from the Terminal. I find OS X's Terminal much more functional and usable than Gnome Terminal on CentOS. For an even better user experience, I recommend SecureCRT, a commercial GUI SSH client for Windows, OS X, and Linux. I *live* in SecureCRT 5 days a week. It is rock solid, and much more capable than Terminal + OpenSSH. OS X's includes an VNC client. You can run it directly, but it's quicker to just say Cmd-G from Finder, then enter vnc://my.box.address in the box that pops up. You can save these URLs for later use, so you don't have to keep retying them. There are several more capable VNC clients, including Apple's own ARD: https://www.apple.com/remotedesktop/ If you can put your CentOS boxes in VMs, OS X is probably the least troublesome VM host I've ever used. OS X is great GUI platform with strong usability norms, but is also a real Unix underneath so VM systems can do everything they need in order to be transparent hosts. Linux fails the first criterion, and Windows fails the second. A particularly nice feature of OS X is the full-screen app mode, which lets you put your VMs on dedicated virtual screens, kind of like virtual desktops feature of some X window managers, except that they are not hosting desktops, but instead app windows that take over the screen completely. Then you can Ctrl-Arrow around to switch OSes, with the keyboard and mouse moving between them seamlessly. I almost never physically touch a CentOS box, even though I use them pretty much every day. Between VNC and SSH, I don't need to. Also consider that a Macbook Pro is plenty powerful enough to run VMs at reasonable speed. In clamshell mode, an MBP is kind of like a mini: http://support.apple.com/kb/ht3131 A mini is far more compact, though, and cheaper. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] ZFS on Linux in production?
On Oct 24, 2013, at 8:01 PM, Lists li...@benjamindsmith.com wrote: Not sure enough of the vernacular Yes, ZFS is complicated enough to have a specialized vocabulary. I used two of these terms in my previous post: - vdev, which is a virtual device, something like a software RAID. It is one or more disks, configured together, typically with some form of redundancy. - pool, which is one or more vdevs, which has a capacity equal to all of its vdevs added together. but lets say you have 4 drives in a RAID 1 configuration, 1 set of TB drives and another set of 2 TB drives. A1 - A2 = 2x 1TB drives, 1 TB redundant storage. B1 - B2 = 2x 2TB drives, 2 TB redundant storage. We have 3 TB of available storage. Well, maybe. You would have 3 TB *if* you configured these disks as two separate vdevs. If you tossed all four disks into a single vdev, you could have only 2 TB because the smallest disk in a vdev limits the total capacity. (This is yet another way ZFS isn't like a Drobo[*], despite the fact that a lot of people hype it as if it were the same thing.) Are you suggesting we add a couple of 4 TB drives: A1 - A2 = 2x 1TB drives, 1 TB redundant storage. B1 - B2 = 2x 2TB drives, 2 TB redundant storage. C1 - C2 = 2x 4TB drives, 4 TB redundant storage. Then wait until ZFS moves A1/A2 over to C1/C2 before removing A1/A2? If so, that's capability I'm looking for. No. ZFS doesn't let you remove a vdev from a pool once it's been added, without destroying the pool. The supported method is to add disks C1 and C2 to the *A* vdev, then tell ZFS that C1 replaces A1, and C2 replaces A2. The filesystem will then proceed to migrate the blocks in that vdev from the A disks to the C disks. (I don't remember if ZFS can actually do both in parallel.) Hours later, when that replacement operation completes, you can kick disks A1 and A2 out of the vdev, then physically remove them from the machine at your leisure. Finally, you tell ZFS to expand the vdev. (There's an auto-expand flag you can set, so that last step can happen automatically.) If you're not seeing the distinction, it is that there never were 3 vdevs at any point during this upgrade. The two C disks are in the A vdev, which never went away. But, XFS and ext4 can do that, too. ZFS only wins when you want to add space by adding vdevs. The only way I'm aware of ext4 doing this is with resizee2fs, which is extending a partition on a block device. The only way to do that with multiple disks is to use a virtual block device like LVM/LVM2 which (as I've stated before) I'm hesitant to do. Yes, implicit in my comments was that you were using XFS or ext4 with some sort of RAID (Linux md RAID or hardware) and Linux's LVM2. You can use XFS and ext4 without RAID and LVM, but if you're going to compare to ZFS, you can't fairly ignore these features just because it makes ZFS look better. btrfs didn't have any sort of fsck Neither does ZFS. btrfs doesn't need an fsck for pretty much the same reason ZFS doesn't. Both filesystems effectively keep themselves fsck'd all the time, and you can do an online scrub if you're ever feeling paranoid. ZFS is nicer in this regard, in that it lets you schedule the scrub operation. You can obviously schedule one for btrfs, but that doesn't take into account scrub time. If you tell ZFS to scrub every day, there will be 24 hours of gap between scrubs. We use 1 week at the office, and each scrub takes about a day, so the scrub date rotates around the calendar by about a day per week. ZFS also has better checksumming than btrfs: up to 256 bits, vs 32 in btrfs. (1 in 4 billion odds of irrecoverable data per block is still pretty good, though.) There was one released a while back that had some severe limitations. This has made me wary. All of the ZFSes out there are crippled relative to what's shipping in Solaris now, because Oracle has stopped releasing code. There are nontrivial features in zpool v29+, which simply aren't in the free forks of older versions o the Sun code. Some of the still-active forks are of even older versions. I'm aware of one popular ZFS implementation still based on zpool *v8*. If all you're doing is looking at feature sets, you can find reasons to reject every single option. There are dkml RPMs on the website. http://zfsonlinux.org/epel.html It is *possible* that keeping the CDDL ZFS code in a separate module manages to avoid tainting the GPL kernel code, in the same way that some people talk themselves into allowing proprietary GPU drivers with DRM support into their kernels. You're playing with fire here. Bring good gloves. [*] or other hybrid RAID system; I don't mean to suggest that only Drobo can do this ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] ZFS on Linux in production?
On 10/25/2013 00:44, John R Pierce wrote: current version of OpenZFS no longer relies on 'version numbers', instead it has 'feature flags' for all post v28 features. This must be the zpool v5000 thing I saw while researching my previous post. Apparently ZFSonLinux is doing the same thing, or is perhaps also based on OpenZFS. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] ZFS on Linux in production?
On 10/25/2013 11:33, Lists wrote: I'm just trying to find the best tool for the job. Try everything. Seriously. You won't know what you like, and what works *for you* until you have some experience. Buy a Drobo for the home, replace one of your old file servers with a FreeBSD ZFS box, enable LVM on the next Linux workstation. That may well end up being Drobo! Drobos are no panacea, either. Years ago, my Drobo FS would disappear from the network occasionally, and have to be rebooted. (This seems to be fixed now.) My boss's first-generation Drobo killed itself in a power outage. It was directly attached to his Windows box, and on restart, chkdsk couldn't find a filesystem at all. A data recovery program was able to pull files back off the disk, though, so it's not like the unit was actually dead. It just managed to corrupt the NTFS data structures thoroughly, despite the fact that it's supposed to be a redundant filesystem. It implies Drobo isn't using a battery-backed RAM cache, for their low-end units at least. Every Drobo I've ever used[*] has been much slower than a comparably-priced dumb RAID. The first Drobos would benchmark at about 20 MByte/sec when populated by disks capable of 100 MByte/sec raw. The two subsequent Drobo generations were touted as faster, but I don't think I ever hit even 30 MByte/sec. Data migration after replacing a disk is also uncomfortably slow. The fastest I've ever seen a disk replacement take is about a day. As disks have gotten bigger, my existing Drobos haven't gotten faster, so now migration might take a week! It's for this single reason that I now refuse to use single-disk redundancy with Drobos. The window without protection is just too big now. A lot of this is doubtless down to the small embedded processor in these things. ZFS on a real computer is simply in a different class. [*] I haven't yet used a Thunderbolt or B series professional version. It is possible they're running at native disk speeds. But then, they're even more expensive. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] ZFS on Linux in production?
On re-reading, I realized I didn't complete some of my thoughts: On 10/25/2013 00:18, Warren Young wrote: ZFS is nicer in this regard, in that it lets you schedule the scrub operation. You can obviously schedule one for btrfs, ...with cron... but that doesn't take into account scrub time. This is important because a ZFS scrub takes absolute lowest priority. (Presumably true for btrfs, too.) Any time the filesystem has to service an I/O request, the scrub stops, then resumes when the I/O request has completed, unless another has arrived in the meantime. This means that you cannot know how long a scrub will take unless you can exactly predict your future disk I/O. Scheduling a scrub with cron could land you in a situation where the previous scrub is still running due to unusually high I/O when another scrub request comes in. I initially set our ZFS file server up so that it would start scrubbing at close of business on Friday, but due to the way ZFS scrub scheduling works, the most recent scrub started late Wednesday and ran into Thursday. This isn't a problem. The scrub doesn't run in parallel to normal I/O, I don't even notice that the array is scrubbing itself unless I go over and watchen das blinkenlights astaunished. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] ZFS on Linux in production?
On 10/24/2013 17:12, Lists wrote: 2) The ability to make the partition bigger by adding drives with very minimal/no downtime. Be careful: you may have been reading some ZFS hype that turns out not as rosy in reality. Ideally, ZFS would work like a Drobo with an infinite number of drive bays. Need to add 1 TB of disk space or so? Just whack another 1 TB disk into the pool, no problem, right? Doesn't work like that. You can add another disk to an existing pool, but it doesn't instantly make the pool bigger. You can make it a hot spare, but you can't tell ZFS to expand the pool over the new drive. But, you say, didn't I read that Yes, you did. ZFS *can* do what you want, just not in the way you were probably expecting. The least complicated *safe* way to add 1 TB to a pool is add *two* 1 TB disks to the system, create a ZFS mirror out of them, and add *that* vdev to the pool. That gets you 1 TB of redundant space, which is what you actually wanted. Just realize, you now have two separate vdevs here, both providing storage space to a single pool. You could instead turn that new single disk into a non-redundant separate vdev and add that to the pool, but then that one disk can take down the entire pool if it dies. Another problem is that you have now created a system where ZFS has to guess which vdev to put a given block of data on. Your 2-disk mirror of newer disks probably runs faster than the old 3+ disk raidz vdev, but ZFS isn't going to figure that out on its own. There are ways to encourage ZFS to use one vdev over another. There's even a special case mode where you can tell it about an SSD you've added to act purely as an intermediary cache, between the spinning disks and the RAM caches. The more expensive way to go -- which is simpler in the end -- is to replace each individual disk in the existing pool with a larger one, letting ZFS resilver each new disk, one at a time. Once all disks have been replaced, *then* you can grow that whole vdev, and thus the pool. But, XFS and ext4 can do that, too. ZFS only wins when you want to add space by adding vdevs. 3) The ability to remove an older, (smaller) drive or drives in order to replace with larger capacity drives without downtime or having to copy over all the files manually. Some RAID controllers will let you do this. XFS and ext4 have specific support for growing an existing filesystem to fill a larger volume. 6) Reasonable failure mode. Things *do* go south sometimes. Simple is better, especially when it's simpler for the (typically highly stressed) administrator. I find it simpler to use ZFS to replace a failed disk than any RAID BIOS or RAID management tool I've ever used. ZFS's command line utilities are quite simply slick. It's an under-hyped feature of the filesystem, if anything. A lot of thought clearly went into the command language, so that once you learn a few basics, you can usually guess the right command in any given situation. That sort of good design doesn't happen by itself. All other disk management tools I've used seem to have just accreted features until they're a pile of crazy. The creators of ZFS came along late enough in the game that they were able to look at everything and say, No no no, *this* is how you do it. I think ZFS and BTRFS are the only candidates that claim to do all the above. Btrfs seems to have been stable in a year or so for as long as I could keep a straight face around the word Gigabyte, so it's a non-starter at this point. I don't think btrfs's problem is stability as much as lack of features. It only just got parity redundancy (RAID-5/6) features recently, for example. It's arguably been *stable* since it appeared in release kernels about four years ago. One big thing may push you to btrfs: With ZFS on Linux, you have to patch your local kernels, and you can't then sell those machines as-is outside the company. Are you willing to keep those kernels patched manually, whenever a new fix comes down from upstream? Do your servers spend their whole life in house? Not as sure about ZFS' stability on Linux (those who run direct Unix derivatives seem to rave about it) and failure modes. It wouldn't surprise me if ZFS on Linux is less mature than on Solaris and FreeBSD, purely due to the age of the effort. Here, we've been able to use FreeBSD on the big ZFS storage box, and share it out to the Linux and Windows boxes over NFS and Samba. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] ZFS on Linux in production?
On 10/24/2013 14:59, John R Pierce wrote: On 10/24/2013 1:41 PM, Lists wrote: 1) you need a LOT of ram for decent performance on large zpools. 1GB ram above your basic system/application requirements per terabyte of zpool is not unreasonable. To be fair, you want to treat XFS the same way. And it, too is unstable on 32-bit systems with anything but smallish filesystems, due to lack of RAM. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SysRq over usb serial adapters
On 9/30/2013 21:34, Barry Brimer wrote: I'm using 115200, 8N1, VT102. I can echo m /proc/sysctl-trigger, and dmesg shows that the sysrq was received when initiated via the procfs interface. But not over serial, and that's what I need. I could be wrong .. but you may need to edit your grub config to convince your system that the serial terminal is a/the console .. That's only part of it. The topic has a whole HOWTO dedicated to it: http://www.tldp.org/HOWTO/Remote-Serial-Console-HOWTO/ ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Linux tool to check random I/O performance
On 9/4/2013 13:44, mcclnx mcc wrote: for sequence I/O performance test we can use hdparm -t /dev/xxx bur for random I/O performance test which Linux command I can use? I use Bonnie++ for that: http://www.coker.com.au/bonnie++/ Actually, I've been using the experimental pre-2.x version: http://www.coker.com.au/bonnie++/experimental/ It's a far better test for sequential I/O than hdparm -Tt, too. ** our environment does NOT allow install third party software.. Not even if it's: a) only for a test b) never installed, and c) removed immediately after the test completes? Bonnie++ is self-contained, easy to build, and will run from the build directory without having to be make installed. You can just remove the build directory when the test is done. There will be no traces that the program was ever present. We won't tell anyone you violated policy. :) ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Macromedia Flash data (compressed), version 9
On 8/13/2013 10:48, Scott Robbins wrote: It seems to me that if firefox could play it from far away, firefox should be able to play it on my computer. So far, that seems not to be the case. What happens if you add .swf to the file's name. This doesn't work because Firefox proper doesn't play .swf files. It hands it off to the Flash Plugin. So, one method is to write a simple .html file, embedding the Flash Plugin, naming the file you have: https://www.google.com/?q=embed+flash+player Another method is to open the file with Chrome, since Chrome *does* have Flash playback built-in. There's a problem here, which is that without the embed stuff, Chrome doesn't know how big to make the SWF object, so it fills the whole content area. It doesn't even maintain the proper aspect ratio, since Chrome doesn't know that, either. If this is important to you, you'll need to write the embed stuff regardless. On Windows, there are Flash Player programs that overcome this problem in other ways, but I don't know of any for Linux. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Motherboard and chipset compatibility
On 8/12/2013 11:01, m.r...@5-cent.us wrote: VERY STRONG RECOMMENDATION: DON'T buy Supermicro. They have a *lot* of trouble with this new, fuzzy concept called quality control. We have a *lot* of SuperMicro based systems in the field, and they aren't failing. In fact, I can't remember the last time we had to fix an actual motherboard issue. It seems like every field hardware failure for years has come down to dying HDDs. We did once upon a time have a QC problem with SuperMicro, around Y2K, but that was because we chose to use AMD processors, and AMD OEM fan/heat sink combos at the time used little 60mm 6000 RPM pancake fans that would seize up after a few years. This was before processors had overtemp shutdown features, so once the fan seized, the processors would cook themselves. You can't really lay that one at SuperMicro's feet. AMD screwed up. The real fix was switching back to Intel processors, which shipped with bigger and slower-moving fans, which lasted longer. You'll notice that both of these failure modes are due to mechanical wear. I can't say I've *ever* seen a SuperMicro board fail in any of the solid-state components, solder joints, capacitors, etc. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Motherboard and chipset compatibility
On 8/12/2013 12:54, m.r...@5-cent.us wrote: Well, *all* of these are rackmount servers, with no moving-the-server wear. Our servers are all rack-mounted, too, and pretty much never get moved after being installed. In any case, I was referring to wear in the electromechanical components of a server. HDDs and fans, primarily. In olden days, optical disks, too. These are expected to fail over time. We start seeing userspace compute-intensive processes crashing the system a number of times a day. Define crash the system. Hard lock-up, requiring a power toggle or Reset press? Server unresponsive to keyboard, except for Ctrl-Alt-Del? Kernel panic? X11 unresponsive but you can still ssh in? User program dies mysteriously, but other programs still run? Keyboard lights blink in patterns, monitor won't wake on mouse wiggle? Box reboots spontaneously? BIOS beeps? I don't suppose you've gathered continuous temp data, say with Cacti? They replace the m/b, and it doesn't happen again. Okay, so either this one motherboard product from Supermicro has a QC problem, or Penguin has an application or design problem with it. Or, your environment is somehow pushing them past their design limits. (e.g. insufficient cooling) You're painting with far too broad a brush here to say Supermicro is bad, period. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] OT: UPS battery vendor, cont'd
On 2/13/2013 06:12, mark wrote: Huh. No, I want to pay on the order of $12/individual battery, Please don't misuse order. It's a corruption of the scientific term order of magnitude[1][2] which, used correctly, means that the values you're comparing use the same factor of 10 in scientific notation. If we take your claim literally, you'd be satisfied with any complete battery that cost less than $120 * 8 = $960. (I will also come after you if you misuse literally. :) ) $100 or so for the set of 8; You've got one low-ball quote, and now you're demanding that everyone else meet it? Sigh... The way I see it is, you've also got a whole bunch of people offering the same thing for $20-30 per VRLA[3] unit. That means either: a) $20-30/VRLA is a good price and consequently you should be worrying about how others are managing to low-ball that; or b) there's widespread price-fixing. Given how many news stories you can find about misbehaving cheap batteries, I'd bet on option a). Just because the label has the same voltage and amp-hour rating as what came out of the APC UPS, doesn't mean it's exactly the same thing. Batteries are tricky. Boeing and Tesla Motors are both in the news now because too few people really understand batteries. If you're willing to open up the APC sled and replace the individual VRLAs directly, the cheapest *reputable* vendor I've found is Mouser. Their part # 632-GP1245 looks close, but don't take my word on that. I'm just eyeballing photos and springboarding off the McMaster dimensions; I have no direct experience on that particular swap. Mouser wants $16.30 each of these in qty 10. Just for reference, one of Mouser's direct competitors, DigiKey, wants about $25 for the same thing. That put's the $22-26 McMaster quote you've tried to reject right in the same range. I also don't see that you're accounting for return shipping and the cost of the sled. If you buy the pack from APC, they ship you a complete, assembled battery pack, along with a reusable box and return shipping label. You put the old one back in the box you got the new one in, and send it back for recycling. That's worth something. When you buy individual VRLAs, you have to account for your time opening up the sled, swapping VRLAs, and reassembling it all. Then you add in your time to dispose of the spent VRLAs. I'm sure you can find plenty of places locally that will take them, but I'll bet your salary and gas costs will wipe out your DIY savings. You're probably not counting opportunity costs[4], either. - [1] https://en.wikipedia.org/wiki/On_the_order_of [2] http://mathworld.wolfram.com/OrderofMagnitude.html [3] https://en.wikipedia.org/wiki/VRLA [4] https://en.wikipedia.org/wiki/Opportunity_cost ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Anything Like Solaris' Live Upgrade?
On 1/29/2013 12:03, Tim Evans wrote: I suppose it's not possible in this forum to ask such a question and not get into religion. Kinda like the U.S. Congress. Um. Yes. shakes head to clear the loony I know you think you're asking for an additional freedom that you feel CentOS doesn't provide, but what you're really looking for is a reason to go back and shackle yourself to a proprietary technology. Wise man say: Free your mind...and your ass will follow. Wise man was on acid when he said that[1] but the point...the POINT I say...is that you're being trapped by a material desire which if satisfied costs more than it's worth when you add in *all* the costs. Kinda like a jelly doughnut. A really big, expensive jelly doughnut. In addition to the problems with proprietary technology, there's at least one more problem with Solaris' boot environment snapshots: they take space, and space costs money. Oh, you say, it only costs a few tens of gigabytes for each system version upgrade. What's the problem in today's terabyte world? Here's the problem: You want to set up a Solaris VM for development and testing, and read that Solaris needs just 7 GB or so to install[2] everything, so you generously give it 20 GB on your laptop.[3] Life is fine: you install some additional software, you do your dev work, you iterate. Then six months later an OS upgrade comes out, you attempt to install it, it runs you out of disk space creating the snapshot, and then fails to boot. (Yes, actual genuine war story. Made in USA.) But wait, weren't snapshots supposed to save me from unbootable systems? Sure, as long as you have prodigious free disk space. I don't know about you, but several gigs of free disk on a VM still feels like a lot to me. You get bit other ways by this feature, too. It requires ZFS, which by most accounts requires 64-bit CPUs and a gig of RAM per terabyte of disk just to manage it. This means that if I give up on my reasonable wish for a 20 GB VM and give it a dedicated HDD or three to play with, now I have to go and set aside beaucoup RAM for it, too. Or maybe a whole system. I'm not saying that all of this is out of reach. Yes, I get the fact that I'm bitching about under $1000 of hardware. My point is that features have a cost, and different OSes charge you different amounts through their designer's choices about which features to include and which to skip for now. In the end, we are in fact talking rationality here, not religion. How much do you want to pay for those features? TANSTAAFL. FWIW, Solaris' problems are not technical. Rather, they're Oracle's licensing and support policies that have essentially fired all its small system customers. That pool is deeper than you realize. Maybe above you were rolling your eyes at my wish for a usable 20 GB OpenSolaris VM. Consider this: I have five or six flavors of Linux on that laptop, plus all the BSDs, Windows 8, and the native OS X. When it comes time for me to test a new version of my software, guess which OS it isn't going to get tested on, purely because I can't afford to dedicate a whole system to it? Or if I *am* fortunate enough to be able to afford a dedicated OpenSolaris box, it's a good chance it isn't where I am now, so it might as well not exist. Do you expect developers like me to multiply the cost by 2, 3, 4x just so we can have a dedicated test box at every development location? Or maybe punch holes in firewalls so we can remotely use a remote box on the back-end somewhere; that isn't free either, once you tally the security risks it buys. Here's why you care about my development problems: if my software doesn't work on your platform, what does it cost you to do the fixes to it to make it work, or seek out an alternative that does work? How many more are there like me who also might like to test on Solaris occasionally if it were easy, but don't because it isn't? How many packages are there with Solaris portability problems as a result? I'd guess there are hundreds of such packages that you personally would like to use, but either can't, or could if you wanted to put in the time to port them yourself. All this because Solaris chased the high end at the expense of the smaller systems. What's happening today to Solaris is simply what happened to all the lesser proprietary Unixes before it. The market's been dissolving from the bottom, and now the mountaintop is dissolving, too. It's the old UnixWare vs Linux arguments, recapitulated. You remember how that story ended, don't you? Yes, I know you're switching to Linux now. What I'm trying to get across is that you should take Linux on its own terms, not try to force it into the Solaris mold. It is the way it is for a pile of good, rational reasons. [1] http://goo.gl/uSIUN [2] http://goo.gl/RnXpW [3] Generous = 10-50% of the free space on a typical laptop SSD.
Re: [CentOS] Anybody running cadence on CentOS 6 ?
On 1/9/2013 12:54, Connie Sieh wrote: Can you add real graphics hardware such as a Nvidia card. Seconded. Why in the world are you trying to run high-end CAD software with chipset graphics? A $200 nVidia board is a round-off error compared to the price paid for the software license and support. If you were only doing 2D stuff, I'd say it might be fine, but your complaint about glxgears tells me you want real-time 3D. So, get a real 3D board. Assuming by Cadence you mean one of the Allegro PCB design products, Cadence has a document that makes this requirement explicit: http://goo.gl/V2E9S Quoting from page 15: A dedicated graphics card with hardware OpenGL support and a minimum of 128MB dedicated (not shared) video RAM and a 128-bit bus interface. (256MB or more is recommended.) We also recommend that the card be workstation certified. (We do not recommend motherboard-based graphics solutions.) Congratulations. Now you don't have to upgrade the OS. :) ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] bind vs nfs
On 11/5/2012 07:56, Leon Fauster wrote: /vhost/one/htdocs/media /vhost/two/htdocs/media /vhost/.../htdocs/media How big does ... get? ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Perl - strict.pm not found
On 10/10/2012 4:38 AM, John Horne wrote: The problem is that 'strict.pm' is located in /usr/share/perl5 (as it is on our other servers), and /usr/share/perl5 is specified in @INC. Perl can do this is when you've run it out of file handles, then someone tries to load a not-previously-loaded Perl module. The Perl interpreter needs one more file handle to open the new module, but it can't get another from the kernel, so it gives that message. Generally this results from a bug in the code, typically one involving an over-reliance on Perl's garbage collector. Perl will close opened file handles for you eventually, but not as long as it thinks they're still being used. If you have a long-running script, you need to be careful about this if it also opens a lot of files, since the default FD limit per process is 1024 on Linux. You can monitor FD usage in a program with ls /proc/`pidof my-program`/fd | wc -l I don't know if you want to put xymon_event in for my-program or something higher up, since I don't know anything about that or ClamAV. Regardless, if you see that number climb continuously, then see the problem happen shortly after the number crests 1000, you've confirmed my guess. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Digi Acceleport Xem
On 9/14/2012 1:50 PM, Sidney Abrahams wrote: I tried that and it worked, but the chkconfig -- add dgap did not. You've added a space to the command, which breaks it. The command is: chkconfig --add dgap ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
