Re: [CentOS] Real sh? Or other efficient shell for non-interactive scripts
On Tue, Apr 28, 2015 at 3:56 AM, Joerg Schilling joerg.schill...@fokus.fraunhofer.de wrote: Les Mikesell lesmikes...@gmail.com wrote: On Mon, Apr 27, 2015 at 2:13 PM, Joerg Schilling joerg.schill...@fokus.fraunhofer.de wrote: Les Mikesell lesmikes...@gmail.com wrote: There was no court case, but VERITAS published a modifed version of gtar where additional code was added by binary only libraries from VERITAS. The FSF did never try to discuss this is public even though everybody did know about the existence. As long as the FSF does not try to sue VERITAS, we are safe - regardless what intentional nonsense you can read on the FSF webpages. I just remembered a counterpoint to this. Back in the Windows 3.0 days when windows had no tcp networking of its own, I put together a DOS binary built from gnutar and the wattcp stack so you could back up a windows or dos box to a unix system via rsh.And when I tried to give it away I was contacted and told that I couldn't distribute it because even though wattcp was distributed in source, it had other conflicts with the GPL. As a side effect of getting it to build on a If you had the wattcp stack in a separate library and if you did make the needed changes for integration in the gtar source, this was fully legal. The source code was separate files, but the binary 'work as a whole' had to be one. I don't think DOS even had a concept of loading binary libraries separate from the main executable. And the binary obviously is controlled by the copyright on the source. So while I don't like it, I can see the point that it does not meet the GPL requirement any more than it would if it were linked to a commercial library that another user would have to purchase. And there's a reasonable chance they could make an equivalent case even where shared libraries can be used, since the intent is the same. I know that the FSF frequently tries to ask people to do things that are not on a legal base. They however know that they cannot go on trial with this... Yes, so, the only way to help keep others from being harmed by this is to dual-license code so they can't possibly make such a claim. It doesn't happen with perl because Larry Wall understood that long ago. Or, if you are so sure of your legal footing, distribute something that they will challenge yourself and win the case that will set the precedent for the rest of us. But I'd guess dual-licensing would be easier and cheaper. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Real sh? Or other efficient shell for non-interactive scripts
On Mon, Apr 27, 2015 at 4:19 PM, Joerg Schilling joerg.schill...@fokus.fraunhofer.de wrote: Do you like to discuss things or do you like to throw smoke grenades? The only thing I'd like to discuss is your reason for not adding a dual license to make your code as usable and probably as ubiquitous as perl. And you have not mentioned anything about how that might hurt you. I explained this to you in vast details. If you ignore this explanation, I cannot help you. No, you posted some ranting misconceptions about why you don't see a need for it. But if you actually believed any of that yourself, then you would see there was no harm in adding a dual license to make it clear to everyone else. It clearly has not hurt the popularity of perl or BSD code to become GPL-compatible, nor has it forced anyone to use that code only in GPL-compatible ways. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Real sh? Or other efficient shell for non-interactive scripts
On Mon, Apr 27, 2015 at 2:13 PM, Joerg Schilling joerg.schill...@fokus.fraunhofer.de wrote: The GPL is all that gives you permission to distribute. If it is void then you have no permission at all to distribute any covered code. Fortunately judges know better than you If you read the reasoning from judgements, you would know that judges just look at the parts of the GPL that are not in conflict with the law. Judges know that making the GPL void as a whole would be a desaster. There is nothing in conflict with law about prohibiting distribution. And you cant' just unilaterally pick parts of the licence that permits distribution that you like and ignore the rest. So apply copyright law without a license. You can't distribute. I agree that the FSF interpretation about distributing source with the intention that the end user does the link with other components is pretty far off the wall, but static binaries are clearly one 'work as a whole' and dynamic linkage is kind of fuzzy.US juries are supposed to focus on intent and are pretty unpredictable - I wouldn't want to take a chance on what they might decide. Given the fact that there is not a single trustworthy lawjer in the US that writes about the GPL and that follows your interpreation, I am relaxed. It's not 'my' interpretation. Nor does my interpretation matter much. It is the owners of the GPL licensed code that would be allowed to claim damages if the GPL terms are not followed. And what they have published is that all of the runtime linked components are included in the 'work as a whole' specification.I assume you are familiar with RIPEM and the reason it could not be distributed until there was a non-GNU implementation of gmp. https://groups.google.com/forum/#!topic/gnu.misc.discuss/4RcHL5Jg14o[1-25] Can you point out a reference to case where this has been validated? That is, a case where the only licence to distribute a component of something is the GPL and distribution is permitted by a court ruling under terms where the GPL does not apply to the 'work as a whole'? There was no court case, but VERITAS published a modifed version of gtar where additional code was added by binary only libraries from VERITAS. The FSF did never try to discuss this is public even though everybody did know about the existence. As long as the FSF does not try to sue VERITAS, we are safe - regardless what intentional nonsense you can read on the FSF webpages. Hardly. One instance by one set of code owners has nothing to do with what some other code owner might do under other circumstances. If you could quote a decision that set a precedent it might be a factor. Cdrtools follow these rules: - No code from CDDL and GPL is mixed into a single file How is 'a file' relevant to the composition of the translated binary where the copyright clearly extends? And why do you have any rules if you think the GPL doesn't pose a problem with combining components? More to the point, why don't you eliminate any question about that problem with a dual license on the code you control? ??? I completely follow the claims from both licenses, so there is no need to follow your wishes. Unless, of course, you actually wanted the code to be used by others or included as components of best-of-breed projects. - Non-GPL code used in a colective work was implemented independently from the GPLd parts and form a separate work that may be used without the GPLd code as well. How 'you' arrange them isn't the point. Or even any individual who builds something that isn't intended for redistribution. But for other people to consider them generally usable as components in redistributable projects there's not much reason to deal with the inability to combine with other widely used components. What's the point - and what do you have against the way perl handles it? You are of course wrong and you ignore everything I explained you before. And likewise you ignore the fact that you would not lose anything with a dual license other than the reason for frequent arguments. And my only question is 'why not'? If your idesyncratic GPL interpretation was true, your whole Linux distro would be illegal. When do you withdraw your Linux distro? How so? Which process links GPL and non-GPL-compatible licensed code into a single work? No one has suggested that it is a problem to distribute separate differently-licensed works together on the same medium or run them on the same box. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Real sh? Or other efficient shell for non-interactive scripts
On Mon, Apr 27, 2015 at 4:34 PM, Joerg Schilling joerg.schill...@fokus.fraunhofer.de wrote: No, you posted some ranting misconceptions about why you don't see a need for it. But if you actually believed any of that yourself, then you would see there was no harm in adding a dual license to make it clear to everyone else. It clearly has not hurt the popularity of perl or BSD code to become GPL-compatible, nor has it forced anyone to use that code only in GPL-compatible ways. Cdrtools are fully legal as they strictly follow all claims from the related licenses. What problem do you have with fully legal code? The problem is that it can't be used as a component of a larger work if any other components are GPL-covered. As you know very well. I explained that because cdrtools is legally distributable as is (see legal reviews from Sun, Oracle and Suse), there is no need to dual license anything. Unless you would like it to be used more widely, and available as component in best-of-breed works. I also explained that a dual licensed source will cause problems if people send e.g. a GPL only patch. So, not being able to accept patches from people who aren't sending patches now - and probably aren't even aware of your work - would somehow be a problem. That's ummm, imaginative... If you continue to claim not to have an answer from me, I need to assume that you are not interested in a serious discussion. I haven't seen any serious discussion yet.Maybe we could discuss how badly perl has suffered from not being able to accept those GPL'd patches that you fear so much. Conclusion: dual licensing is not helpful and it even has disadvantages. Wrong conclusion. Remind we why you asked about your code not being used. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Find installed yum groups?
On Mon, Apr 27, 2015 at 4:34 PM, Matthew Miller mat...@mattdm.org wrote: On Mon, Apr 27, 2015 at 04:04:41PM -0500, Les Mikesell wrote: Interesting, but it seems to _only_ show groups that weren't included in the anaconda install. For example where the saved anaconda-ks-cfg shows @gnome-desktop and @development, 'yum grouplist' only shows 'MATE Desktop' which was installed later. Does the hidden flag help here? Well it's different, but still doesn't seem right. That shows: Installed environment groups: MATE Desktop and Installed groups: Core Dial-up Networking Support Fonts Guest Desktop Agents Input Methods MATE Multimedia but still no mention of development or gnome. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Real sh? Or other efficient shell for non-interactive scripts
On Mon, Apr 27, 2015 at 2:28 PM, Joerg Schilling joerg.schill...@fokus.fraunhofer.de wrote: as a whole means generally BUT allowing for exceptions. OK, great. That clears it up then. Maybe this helps: The BSD license does not permit to relicense the code, so you cannot put BSD code under the GPL. Yes, if you mean what is described here as 'the original 4-clause' license, or BSD-old: http://en.wikipedia.org/wiki/BSD_licenses The BSD license permits to mix a source file under BSD license with some lines under a different license if you document this. But this is not done in all cases I am aware of. But you can't add the 'advertising requirement' of the 4-clause BSD to something with a GPL component because additional restrictions are prohibited. Up to now, nobody could explain me how a mixture of GPL and BSD can be legal as this would require (when following the GPL) to relicense the BSD code under GPL in order to make the whole be under GPL. In other words, if you can legally combine BSD code with GPL code, you can do with GPL and CDDL as well. You can't do either if you are talking about the BSD-old license (which also isn't accepted as open source by the OSI). Fortunately, the owners of the original/official BSD were nice guys and removed the GPL incompatible clause, with the Revised BSD License being recognized as both open source and GPL-compatible. But that hasn't - and probably can't - happen with CDDL, so the only working option is dual licensing. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Find installed yum groups?
On Mon, Apr 27, 2015 at 1:47 PM, Matthew Miller mat...@mattdm.org wrote: On Mon, Apr 27, 2015 at 11:58:08AM -0500, Les Mikesell wrote: Is there an 'after the fact' way to find what yum groups are installed, including ones that were added with 'yum groupinstall' instead of the initial anaconda install? Yes. yum grouplist will tell you the groups that are currently in the installed state. Worth reading the manpage to see exactly what yum thinks that installed means: Groups are marked as installed if all mandatory packages are installed, or if a group doesn’t have any mandatory packages then it is installed if any of the optional or default package are installed. [...] Interesting, but it seems to _only_ show groups that weren't included in the anaconda install. For example where the saved anaconda-ks-cfg shows @gnome-desktop and @development, 'yum grouplist' only shows 'MATE Desktop' which was installed later. What I am looking for is a succinct way to duplicate the full installed package list that exists on an organically-developed developed system (that is, where people added things until it all worked), so equivalent systems can be created by a minimal install followed by a scripted yum install 'big list of stuff'. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Real sh? Or other efficient shell for non-interactive scripts
On Mon, Apr 27, 2015 at 4:04 PM, Joerg Schilling joerg.schill...@fokus.fraunhofer.de wrote: Yes, if you mean what is described here as 'the original 4-clause' license, or BSD-old: http://en.wikipedia.org/wiki/BSD_licenses Do you like to discuss things or do you like to throw smoke grenades? The only thing I'd like to discuss is your reason for not adding a dual license to make your code as usable and probably as ubiquitous as perl. And you have not mentioned anything about how that might hurt you. In other words, if you can legally combine BSD code with GPL code, you can do with GPL and CDDL as well. You can't do either if you are talking about the BSD-old license (which also isn't accepted as open source by the OSI). Fortunately, the owners of the original/official BSD were nice guys and removed the GPL incompatible clause, with the Revised BSD License being recognized as both open source and GPL-compatible. But that hasn't - and probably can't - happen with CDDL, so the only working option is dual licensing. It seems that you are not interested in a sesrious discussion. Not unless it is about how you or anyone else would be hurt by a dual license. Anything else is just ranting on both our parts. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Find installed yum groups?
On Mon, Apr 27, 2015 at 4:52 PM, Les Mikesell lesmikes...@gmail.com wrote: On Mon, Apr 27, 2015 at 4:34 PM, Matthew Miller mat...@mattdm.org wrote: On Mon, Apr 27, 2015 at 04:04:41PM -0500, Les Mikesell wrote: Interesting, but it seems to _only_ show groups that weren't included in the anaconda install. For example where the saved anaconda-ks-cfg shows @gnome-desktop and @development, 'yum grouplist' only shows 'MATE Desktop' which was installed later. Does the hidden flag help here? Well it's different, but still doesn't seem right. That shows: Installed environment groups: MATE Desktop and Installed groups: Core Dial-up Networking Support Fonts Guest Desktop Agents Input Methods MATE Multimedia but still no mention of development or gnome. And I guess the other piece of this would be finding individual packages that are not encompassed by the groups - or pulled in by dependencies.Is there some database-like approach to take the full list of packages, then reduce it to the minimal list of groups and top-level packages to pull the rest in? It probably will work to hand the raw list to yum but I'd like to make an understandable list in a script even if the packages had been added piecemeal in the first place as someone noticed the need for them. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Real sh? Or other efficient shell for non-interactive scripts
On Mon, Apr 27, 2015 at 10:07 AM, Joerg Schilling joerg.schill...@fokus.fraunhofer.de wrote: I would be interested to understand why Heirloom seems to so well known and my portability attempts seem to be widely unknown. Not sure why it matters with a standalone application like sh, but I think a lot of people have been put off by the GPL incompatibility with your tools. If you want popularity - and usability, a dual-license would work as perl shows. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Real sh? Or other efficient shell for non-interactive scripts
On Mon, Apr 27, 2015 at 10:46 AM, Joerg Schilling joerg.schill...@fokus.fraunhofer.de wrote: And the problem is the GPL. I recommend you to work on making all GPL code freely combinable with other OSS. Of course the problem it the GPL. Glad you recognize that. It's whole point is the restriction against linking with anything with an incompatible license which obviously prevents a lot of best-of-breed combinations. My code is fully legal and there is absolutely no license problem with it. Umm, no. Larry Wall clearly understood this eons ago. Just do not follow the false claims from some OSS enemies...and believe the lawyers that checked my code ;-) My code was audited by Sun legal, Oracle legal and by the legal department from SuSe. Sure, there is nothing 'wrong' with your licence as long as it isn't mixed with anything with different restrictions. Just don't act surprised that the code doesn't get used in projects that have to accommodate GPL restrictions. Question: when will RedHat follow the legal audits from these companies? Question: If _you_ believe that it is OK to mix your code with GPL'd code, why not add the dual licensing statement that would make it clear for everyone else? It doesn't take anything away - unless you really don't want it to be used in other projects. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Real sh? Or other efficient shell for non-interactive scripts
On Mon, Apr 27, 2015 at 11:16 AM, Joerg Schilling joerg.schill...@fokus.fraunhofer.de wrote: You should read the GPL and get help to understand it. The GPL does not forbid this linking. In contrary, the GPOL allows any GPLd program to be linked against any library under and license. If this was not thecase, you could not legally distribute binaries from GPLd programs. You can't distribute GPLd programs unless 'the work as a whole' is covered by the GPL. There can't be a distinction between binary and source since one is derived from the other. My code is fully legal and there is absolutely no license problem with it. Umm, no. Larry Wall clearly understood this eons ago. ??? Odd, I expected you to be as smart as him. He started with only the 'Artistic' license but quickly understood the issues when you need part of the 'work as a whole' to include, say, linking in a proprietary database driver as one component and GPL'd readline as another, along with the code he wanted to be generally usable. And he did something about it. Sure, there is nothing 'wrong' with your licence as long as it isn't mixed with anything with different restrictions. Just don't act surprised that the code doesn't get used in projects that have to accommodate GPL restrictions. Again, don't follow the agitation from OSS enemies. You are of course wrong! You don't have to 'follow' anything - just read the phrase 'work as a whole'. Question: If _you_ believe that it is OK to mix your code with GPL'd code, why not add the dual licensing statement that would make it clear for everyone else? It doesn't take anything away - unless you really don't want it to be used in other projects. Why should I do something that is not needed? My question is 'why not do it?'. You don't lose anything but the restrictions that you pretend aren't there since a dual license allows you to choose the terms of the other if you prefer. I don't like the GPL restrictions either, but I just say so instead of pretending otherwise. A dual license is clearly needed unless your point is to make people choose between either using your code or anything that is GPL'd. But before you like to discuss things with me, I recommend you to first inform yourself correctly. I if course _don't_ mix CDDLd code with GPLd code. So, you really don't want your code to be used?Then why ask why it isn't popular? -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Real sh? Or other efficient shell for non-interactive scripts
On Mon, Apr 27, 2015 at 11:41 AM, Warren Young w...@etr-usa.com wrote: 4. CDDL annoys a lot of people. The CDDL does not annoy people, this is just a fairy tale from some OSS enemies. The following irritates me, I am a “people,” and I am not an OSS enemy: http://zfsonlinux.org/faq.html#WhatAboutTheLicensingIssue It is really the GPL that has the restriction preventing 'best-of-breed' components being combined, but it doesn't matter, it isn't going to change. I can see Sun being irritated with Linux (and for good reason...) but isn't it time to let it go? -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Find installed yum groups?
Is there an 'after the fact' way to find what yum groups are installed, including ones that were added with 'yum groupinstall' instead of the initial anaconda install? -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Real sh? Or other efficient shell for non-interactive scripts
On Mon, Apr 27, 2015 at 2:13 PM, Joerg Schilling joerg.schill...@fokus.fraunhofer.de wrote: Les Mikesell lesmikes...@gmail.com wrote: There was no court case, but VERITAS published a modifed version of gtar where additional code was added by binary only libraries from VERITAS. The FSF did never try to discuss this is public even though everybody did know about the existence. As long as the FSF does not try to sue VERITAS, we are safe - regardless what intentional nonsense you can read on the FSF webpages. I just remembered a counterpoint to this. Back in the Windows 3.0 days when windows had no tcp networking of its own, I put together a DOS binary built from gnutar and the wattcp stack so you could back up a windows or dos box to a unix system via rsh.And when I tried to give it away I was contacted and told that I couldn't distribute it because even though wattcp was distributed in source, it had other conflicts with the GPL. As a side effect of getting it to build on a DOS compiler, I prototyped the tar code and contributed that and some bugfixes. Someone else's version was accepted instead but at least my name is still in a comment somewhere. Probably the only thing still being distributed... -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Real sh? Or other efficient shell for non-interactive scripts
On Mon, Apr 27, 2015 at 12:10 PM, Joerg Schilling joerg.schill...@fokus.fraunhofer.de wrote: If you combine ZFS and Linux, you create a permitted collective work and the GPL cannot extend it's rules to the CDDLd separate and independend work ZFS of course. Which countries' copyright laws would permit that explicitly even when some of the components' licenses prohibit it? -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Real sh? Or other efficient shell for non-interactive scripts
On Mon, Apr 27, 2015 at 11:57 AM, Joerg Schilling joerg.schill...@fokus.fraunhofer.de wrote: You can't distribute GPLd programs unless 'the work as a whole' is covered by the GPL. There can't be a distinction between binary and source since one is derived from the other. Now you just need to understand what as a whole means Apparently we live in different universes. Or at least countries - where meanings are relative. But it doesn't matter how either of us understand it, what matters are how the legal system understands it in our native countries. Try to be clever and try to inform yourself before sending more fals claims as you did already. Maybe you are a native english speaker and thus lazy with reading the GPL. If you carefully read the GPL, you of course understand that it is _very_ careful about what parts the GPL applies to. It definitely does _not_ apply to the complete source. Yes, in english, 'work as a whole' does mean complete. And the normal interpretation is that it covers everything linked into the same process at runtime unless there is an alternate interface-compatible component with the same feature set. If you have problems to understand the GPL, read one of the various comments from lawyers, but avoid Mr. Moglen - he is well known for intentionally writing false claims in the public and only uses correct lawful interpretations if he is in a private discussion. No one is interested in setting themselves up for a legal challenge with opposing views by experts. And fortunately, Larry didn't publish patch under GPL, so I was able to write a non-GPLd POSIX compliant patch (note that gpatch is not POSIX compliant). Larry is a nice guy. He doesn't want to cause trouble for anyone. Apparently that's not universal You don't have to 'follow' anything - just read the phrase 'work as a whole'. You need to _understand_ the GPL and avoid to just lazyly read it as you did before. The GPL does _not_ apply to _everything_. The GPL just applies to the work that is under GPL. For the rest, you just need to include it under _any_ license and if you did ever carefully read the GPL, you of course did know that already. It applies to everything copyright law applies to since it is really copyright law that restricts distribution and the GPL simply provides the exceptions. There's a valid case for linked components to be considered derivative works of each other if they require the other for the work as a whole to be functional. Fazit: The GPL does not require you to put everything under GPL. It just requires you to include makefiles, scripts and libraries under any license that permits redistribution. Those are mentioned separately because they wouldn't be included as a derivative work otherwise. My question is 'why not do it?'. You don't lose anything but the restrictions that you pretend aren't there since a dual license allows you to choose the terms of the other if you prefer. I don't like the GPL restrictions either, but I just say so instead of pretending otherwise. A dual license is clearly needed unless your point is to make people choose between either using your code or anything that is GPL'd. If I did add the GPL to my code, I would not win anything, because antisocial people would still prevent it from being included in Debian or RedHat. Beg your pardon? You lost me here. If you remove the reason for exclusion, what evidence do you have that the work would still be excluded, other than perhaps your long history of keeping it from being usable? I would however risk that people send interesting patches as GPL only and this way prevent the freedom to use it by anybody. And that would be different howYou can't use them now. And worse, you've severely restricted the number of people who might offer patches regardless of the license. But before you like to discuss things with me, I recommend you to first inform yourself correctly. I if course _don't_ mix CDDLd code with GPLd code. So, you really don't want your code to be used?Then why ask why it isn't popular? Please explain me why people believe RedHat or Centos is a good choice when there are people inside that write false claims on the GPL because they did not read it in a way that would allow them to understand the GPL? How do you imagine such a 'false claim' affects anyone's use of released code and source or why it would be a factor in their choice? Personally I can't reconcile RedHat's restriction on redistributing binaries with the GPL's prohibition on additional restrictions, but Centos makes that a non-issue. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Real sh? Or other efficient shell for non-interactive scripts
On Mon, Apr 27, 2015 at 1:02 PM, Joerg Schilling joerg.schill...@fokus.fraunhofer.de wrote: The GPL makes claims that are in conflict with the law because these claims are not amongst what the list in the law permits and that are thus void. The GPL is all that gives you permission to distribute. If it is void then you have no permission at all to distribute any covered code. Both legal systems have the same results: They prevent the GPL from using it's own interpretation os what a derivative work is and the rules from the laws apply instead. So apply copyright law without a license. You can't distribute. I agree that the FSF interpretation about distributing source with the intention that the end user does the link with other components is pretty far off the wall, but static binaries are clearly one 'work as a whole' and dynamic linkage is kind of fuzzy.US juries are supposed to focus on intent and are pretty unpredictable - I wouldn't want to take a chance on what they might decide. These rules make many combinations a collective work that is permitted. The cdrtools and ZFS on Linux match these rules - well, I assume that the ZFS integration code follows the rules that are needed for a clean collective work. Can you point out a reference to case where this has been validated? That is, a case where the only licence to distribute a component of something is the GPL and distribution is permitted by a court ruling under terms where the GPL does not apply to the 'work as a whole'? Cdrtools follow these rules: - No code from CDDL and GPL is mixed into a single file How is 'a file' relevant to the composition of the translated binary where the copyright clearly extends? And why do you have any rules if you think the GPL doesn't pose a problem with combining components? More to the point, why don't you eliminate any question about that problem with a dual license on the code you control? - Non-GPL code used in a colective work was implemented independently from the GPLd parts and form a separate work that may be used without the GPLd code as well. How 'you' arrange them isn't the point. Or even any individual who builds something that isn't intended for redistribution. But for other people to consider them generally usable as components in redistributable projects there's not much reason to deal with the inability to combine with other widely used components. What's the point - and what do you have against the way perl handles it? -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Real sh? Or other efficient shell for non-interactive scripts
On Mon, Apr 27, 2015 at 1:46 PM, Always Learning cen...@u64.u22.net wrote: Yes, in english, 'work as a whole' does mean complete. And the normal interpretation is that it covers everything linked into the same process at runtime unless there is an alternate interface-compatible component with the same feature set. That may be the USA interpretation but on the other, European, side of the Atlantic I believe as a whole means generally BUT allowing for exceptions. OK, great. That clears it up then. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Real sh? Or other efficient shell for non-interactive scripts
On Fri, Apr 24, 2015 at 7:02 AM, mark m.r...@5-cent.us wrote: I'm sure most people here know about Dash in Debian. Have there been discussions about providing a more efficient shell in Centos for use with heavily invoked non-interactive scripts? With sh being a link to bash in Centos I don't know if it would explode if the link was changed to something else, but at least the scripts we made on our own that run certain services could be changed and tested manually to another shell. Are there other people who have experience in this and can provide interesting guidance? Why go to that extreme if you tell a script on line 1 which shell to run it will do so. #!/bin/dash or what ever shell you want it to run in. I always do that to make sure that the script runs as expected, if you leave it out the script will run in whatever environment it currently is in. I'm confused here, too, and this has been bugging me for some time: why sh, when almost 20 years ago, at places I've worked, production shell scripts went from sh to ksh. It was only after I got into the CentOS world in '09 that I saw all the sh scripts again. The original ksh wasn't open source and might even have been an extra-cost item in ATT unix. And the early emulations weren't always complete so you couldn't count on script portability. I generally thought it was safer to use perl for anything that took more than bourne shell syntax. But as for efficiency, I'd think a script would have to do quite a lot of work to offset the need to page in different code for the interpreter. Any unix-like system should almost always have some instances of sh running and other instances of the same executable should run shared-text, where invoking a shell that isn't already loaded will have to load the code off the disk. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Real sh? Or other efficient shell for non-interactive scripts
On Fri, Apr 24, 2015 at 12:04 PM, John R Pierce pie...@hogranch.com wrote: On 4/24/2015 9:47 AM, Gordon Messmer wrote: On 04/24/2015 03:57 AM, Pete Geenhuizen wrote: if you leave it out the script will run in whatever environment it currently is in. I'm reasonably certain that a script with no shebang will run with /bin/sh. I interpret your statement to mean that if a user is using ksh and enters the path to such a script, it would also run in ksh. That would only be true if you sourced the script from your shell. oh fun, just did some tests (using c6.latest). if you're in bash, ./script (sans shebang) runs it in bash. if you're in dash or csh, ./script runs it in sh.if you're in ksh, it runs it in ksh. If I'm doing cron jobs or a top-level control script I usually just specify the interpreter explicitly like cd somewhere sh some_script.sh cd somewhere_else perl some_script.pl so it works even if I forget to chmod it executable... -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Real sh? Or other efficient shell for non-interactive scripts
On Fri, Apr 24, 2015 at 11:12 AM, John R Pierce pie...@hogranch.com wrote: On 4/24/2015 3:07 AM, E.B. wrote: I'm sure most people here know about Dash in Debian. Have there been discussions about providing a more efficient shell in Centos for use with heavily invoked non-interactive scripts? perl or python are much better choices for complex scripts that need decent performance Yes, the shell is great at launching other programs, redirecting i/o, creating pipes, expanding wildcard filenames and generally automating things with exactly the same syntax you'd use manually on the command line. But not so much at doing real computation itself. Even with perl if you have to do serious work you'll probably want modules that link in compiled C libraries. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Real sh? Or other efficient shell for non-interactive scripts
On Fri, Apr 24, 2015 at 3:04 PM, m.r...@5-cent.us wrote: My first RH was 5, late nineties. First time I looked at linux and installed, it was '95, and slack. (We'll ignore the Coherent that I installed on my beloved 286 in the late 80's). snip You mean you missed all the fun with Xenix on Radio Shack Model 16's and SysV on ATT's weird 3b machines? -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Real sh? Or other efficient shell for non-interactive scripts
On Fri, Apr 24, 2015 at 3:45 PM, E.B. emailbuilde...@yahoo.com wrote: Interesting thread i started! Sorry if my question was too vague: -- On Fri, 4/24/15, Joerg Schilling joerg.schill...@fokus.fraunhofer.de wrote: The Bourne Shell is also much faster than bash. In special on platforms like Cygwin, where Microsoft enforces extremly slow process creation. This gets at what I was thinking. For scripts that are not run interactively, it seems wasteful to load all of Bash autocomplete, command history and all its rich features. For running in high volume mail server for example, *short* scripts that take a few input args and invoke another program. Or do a mysql update (but it has been pointed out invoking mysql from a shell script is also inefficient since mysql client is also very feature rich with command history and things). Or take some arguments and make a curl HTTP request somewhere. So my question is should I install ksh (I see it is available in yum centos base repo) and use that? Or should we consider to rewrite these short scripts to perl? I read on the web that perl with a few typical libraries is far slower to start up than a shell script. ?? (no heavy computations) I'd do some serious timing tests in your typical environment before believing anything about this. The part that takes substantial time is if you have to load code from disk. Anything already running (loaded from the same inode, so including hard links to different names) should run shared-text without loading a new copy (also saving memory...). Anything that had been loaded recently but needs a new copy should be reloaded quickly from cache. Loading a new instance of some little used interpreter is going to hit the disk. Your most likely win would be to consolidate operations into longer scripts and use perl where it can do work that would involve several other programs as shell commands. For example, I'd expect a single perl program with several mysql operations to be much faster than a shell script that needs to invoke mysql more than once - plus it is a lot easier to access the data in a perl program. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] IP aliases for services (including dhcpd)?
I'd like to consolidate the services from several old servers onto 2 CentOS7 VMs that are currently running dhcpd in a balanced/failover configuration. It will simplify things to add the IPs from the old servers as aliases, at least temporarily so everything will continue to connect without changes. However, after adding the first one, I see in the logs that DHCPD is sending its DHCPACKs alternating between ens192 and ens192:0 every other time, but oddly it is always using the non-alias IP as the source every time according to tcpdump -n. Is this configuration likely to confuse anything? -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] IP aliases for services (including dhcpd)?
On Wed, Apr 22, 2015 at 2:49 PM, David Both db...@millennium-technology.com wrote: Yes confusion will abound. There should only ever be one and only one DHCP server on any network. With two you will sooner of later have multiple DHCP client hosts with the same IP addresses. No, it's not going to give out duplicate IPs. The dual servers are configured as primary/secondary and know about each other with some protocol to track what leases are already out. https://kb.isc.org/article/AA-00502/0/A-Basic-Guide-to-Configuring-DHCP-Failover.html My question is just about multiple IPs as aliases on the server side. So far it looks like it is always sending with the same source IP even though it logs that it used the alias interface name. I'm just wondering if it would confuse clients if it gets an IP from one source and subsequent ACKs from another. But, I guess that has been happening for a long time already with the dual server setup. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] How to stagger fsck executions
On Tue, Apr 21, 2015 at 11:40 AM, Hugh E Cruickshank h...@forsoft.com wrote: From: Les Mikesell Sent: April 21, 2015 09:19 Why do you care about running them at the same time when it doesn't take longer to run them all in parallel? Except I think the root filesystem normally runs first. So you might want to stagger it vs. everything else. I am trying to avoid running them at the same time in an effort to avoid 70 minute boot times (which is what happened on the weekend). How many filesystems do you have? If you look at ./etc.fstab, everything where the final number is '1' (normally just the root filesystem) should complete first, then everything with a 2 will run at once. If the other mounts are each on different drive/spindles they won't conflict with each other and will complete in the same time as running just the largest one of them. If you are running fscks of partitions on the same drive in parallel it will obviously go slower. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] How to stagger fsck executions
On Tue, Apr 21, 2015 at 11:01 AM, Hugh E Cruickshank h...@forsoft.com wrote: Thanks but changing the order of execution or executing them in parallel does not help with executing them one per reboot. Why do you care about running them at the same time when it doesn't take longer to run them all in parallel? Except I think the root filesystem normally runs first. So you might want to stagger it vs. everything else. And unless you reboot frequently you are probably hitting the time setting, not the mount count. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] systemd private tmp dirs
On Thu, Apr 16, 2015 at 6:58 AM, Dennis Jacobfeuerborn denni...@conversis.de wrote: No, systemd actually remaps /tmp from apache - and apparently most other daemons - to private directories below /tmp with configs as shipped. The command line tool wrote the file to /tmp as expected. The perl code running under httpd reading what it thought was /tmp was actually looking under /tmp/systemd-private-something. I'm beginning to see why so much of EPEL isn't included in epel7 yet. The issue here really isn't systemd or the PrivateTmp feature but the fact that some applications don't properly distinguish between temporary files and data files. Maybe, but if an application wants a private directory for temporary files, shouldn't it create and manage that directory itself instead of being second-guessed by the default configuration of the OS? Temporary files are files the application generates temporarily for internal processing and that are not to be touched by anybody else. If as in the twiki backup case the files generated are to be used by somebody else after twiki is done generating them then these are regular data files and not temporary files. This is very fuzzy... It is really all the application code creating/reading the files, and they are intended to be created at least daily with timestamps in the name and not live forever. The application should have a configuration option to set its data directory and it should default to /var/lib/application-name. In cases where this option is not available and the application abuses the tmp directory as data directory there is probably no other option than to the set PrivateTmp=false in the service file. It does that - the issue is just that it is handy (and common) to use cron to do the scheduled runs and what the application sees as absolute file paths are perverted by the system into something surprising. The 'modern' approach might be to provide a rest type interface in the web application so the cron job could use wget/curl to access a URL instead of running the perl code itself. But that's also kind of weird to have to do to get a consistent view of the filesystem.And as far as what the default location should be - what would be correct for portable code? Isn't /var/lib/something kind of linux-centric? Where can an application expect to be able to write? -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] ClamAV reports a trojan
On Thu, Apr 16, 2015 at 10:01 AM, James B. Byrne byrn...@harte-lyne.ca wrote: This morning I discovered this in my clamav report from one of our imap servers: /usr/share/nmap/scripts/irc-unrealircd-backdoor.nse: Unix.Trojan.MSShellcode-21 FOUND I have looked at this script and it appears to be part of the nmap distribution. It actually tests for irc backdoors. IRC is not used here and its ports are blocked by default both at the gateway and on all internal hosts. However, I none-the-less copied that file, removed namp, re-installed nmap from base, and diffed the file of the same name installed with nmap against the copy. They are identical. The question is: Do I have a problem here or a false positive? I am not sure why nmap is on that host but evidently I had some reason last October to use it from that server. In any case I am going to remove it for good, or at least until the reason I had it there reoccurs or is recalled to mind. If everything is rpm-installed you can say: rpm -q --whatprovides /usr/share/nmap/scripts/irc-unrealircd-backdoor.nse and see what package installed it and; rpm -Vv packagename to verify that the files still match what the package installed. (which, of course doesn't tell you if the files are trojans or not, just that they came from a presumably signed package and haven't been modified subsequently). -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] systemd private tmp dirs
On Thu, Apr 16, 2015 at 9:25 AM, Matthew Miller mat...@mattdm.org wrote: On Thu, Apr 16, 2015 at 07:44:21AM -0500, Les Mikesell wrote: The issue here really isn't systemd or the PrivateTmp feature but the fact that some applications don't properly distinguish between temporary files and data files. Maybe, but if an application wants a private directory for temporary files, shouldn't it create and manage that directory itself instead of being second-guessed by the default configuration of the OS? This one I have a clear answer for: no. It's the distribution's job to help regularize application practices, especially when they don't follow good practices for security. Really? I would have expected that it was the distribution's job to not surprise coders or administrators. Particularly for 'enterprise' operating systems where the point is to keep the same application working the same way, often for the life of a company. Ideally, we work with upstreams on this, but sometimes where it's just a matter of configuration, we choose to exercise options to make everything fit together. I typically have many web 'applications' running on the same system under the same apache instance, distinguished only by the top level directory in the url. Even if it made sense to someone to surprise these applications by remapping the filesystem for some reason, why would it make sense for them to share what the system thinks it is making private? -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] systemd private tmp dirs
Is there a generic way that processes written to share files with (say) apache in /tmp can figure out that they are running on an OS with systemd and in that case, where the daemon in question thinks /tmp is? For example, twiki has a backup/restore add-in where the backup part is normally done from cron with a command line script but the resulting archives that go in /tmp are supposed to be seen in the web interface where you can choose and restore from them. How should that have been written so the file lands where systemd has remapped /tmp for httpd if it happens to be running on a host with systemd? -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] systemd private tmp dirs
On Wed, Apr 15, 2015 at 5:01 PM, Matthew Miller mat...@mattdm.org wrote: On Wed, Apr 15, 2015 at 04:15:23PM -0500, Les Mikesell wrote: Why does this directory have to be /tmp rather than a specific directory belonging to twiki? Twiki is a perl web application run under apache. It doesn't have its own uid. It doesn't 'have' to be anywhere in particular but that is the way it was written and thus has very confusing results when trying to move it to CentOS 7. Is there some generic approach to fixing this kind of breakage (that is, to make it work and not confusing, not to say it was broken as designed)?To function as a backup, it probably shouldn't default to being in the same directory as the files it backs up. There are two (sane) options, I think. The first, and I think the best, is to configure twiki to share files in some specific location rather than /tmp. It doesn't have to be the same directory as the files being backed up — maybe something under /var/lib/twiki (or /var/local/twiki). If the twiki backup plugin didn't allow this to be configured, I would argue that it _is_ broken by design. But a quick Google search leads me to http://twiki.org/cgi-bin/view/Plugins/BackupRestorePlugin, which shows that it is indeed configurable, so I'm just going to call it a questionable default. :) If you want to keep that default, though, the second approach would be to configure Apache to not use a private namespace, which I don't recommend because you lose the security benefit. To do that, put [Service] PrivateTmp=false in /etc/systemd/system/httpd.service (which may not exist). Thanks - I can see how those would work once you understand what is broken on the target system and why, but is there a way that programs 'should' be written to run with/without systemd? That just happened to be the first thing I've tried to move over that wasn't already packaged and adapted - I expect to hit many more. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] systemd private tmp dirs
On Wed, Apr 15, 2015 at 9:00 PM, John R Pierce pie...@hogranch.com wrote: On 4/15/2015 6:52 PM, Les Mikesell wrote: Mostly I'm interested in avoiding surprises and having code that isn't married to the weirdness of any particular version of any particular distribution. And I found this to be pretty surprising, given that I could see the file in /tmp and could read the code that was looking there. So, from the point of view of writing portable code, how should something handle this to run on any unix-like system? you sure this had nothing to do with selinux not letting perl running as the http user write there? No, systemd actually remaps /tmp from apache - and apparently most other daemons - to private directories below /tmp with configs as shipped. The command line tool wrote the file to /tmp as expected. The perl code running under httpd reading what it thought was /tmp was actually looking under /tmp/systemd-private-something. I'm beginning to see why so much of EPEL isn't included in epel7 yet. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] systemd private tmp dirs
On Wed, Apr 15, 2015 at 6:48 PM, Matthew Miller mat...@mattdm.org wrote: On Wed, Apr 15, 2015 at 05:31:52PM -0500, Les Mikesell wrote: Thanks - I can see how those would work once you understand what is broken on the target system and why, but is there a way that programs 'should' be written to run with/without systemd? That just happened to be the first thing I've tried to move over that wasn't already packaged and adapted - I expect to hit many more. This isn't really a systemd thing. It's a standard Linux kernel feature, which could also be enabled with (for example) pam_namespace. Systemd happens to make it easy, so we started enabling it for services which would benefit on Fedora, and that was inherited into RHEL and CentOS. See the change page for this https://fedoraproject.org/wiki/Features/ServicesPrivateTmp. If you're really interested in learning every possible thing about systemd, you could of course go through the author's blog post series systemd for administrators — see http://0pointer.de/blog/projects/systemd-for-admins-1.html. It's pretty useful. Or, if you're mostly interested in packaging something up to run in a nice way in the Fedora/RHEL/CentOS-ecosystem, the Fedora packaging guidelines for systemd might help; those are at http://fedoraproject.org/wiki/Packaging:Systemd. I notice that private temp dirs aren't mentioned there (not a bad thing to add, really) but you'll find some other advice that might be helpful. (Take a look at private devices and networking for a related issue.) Mostly I'm interested in avoiding surprises and having code that isn't married to the weirdness of any particular version of any particular distribution. And I found this to be pretty surprising, given that I could see the file in /tmp and could read the code that was looking there. So, from the point of view of writing portable code, how should something handle this to run on any unix-like system? -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] systemd private tmp dirs
On Wed, Apr 15, 2015 at 4:07 PM, Matthew Miller mat...@mattdm.org wrote: On Wed, Apr 15, 2015 at 03:55:34PM -0500, Les Mikesell wrote: Is there a generic way that processes written to share files with (say) apache in /tmp can figure out that they are running on an OS with systemd and in that case, where the daemon in question thinks /tmp is? For example, twiki has a backup/restore add-in where the backup part is normally done from cron with a command line script but the resulting archives that go in /tmp are supposed to be seen in the web interface where you can choose and restore from them. How should that have been written so the file lands where systemd has remapped /tmp for httpd if it happens to be running on a host with systemd? Why does this directory have to be /tmp rather than a specific directory belonging to twiki? Twiki is a perl web application run under apache. It doesn't have its own uid. It doesn't 'have' to be anywhere in particular but that is the way it was written and thus has very confusing results when trying to move it to CentOS 7. Is there some generic approach to fixing this kind of breakage (that is, to make it work and not confusing, not to say it was broken as designed)?To function as a backup, it probably shouldn't default to being in the same directory as the files it backs up. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] what updates /etc/localtime?
I see in CentOS 7 that /etc/localtime is a symlink (which seems sensible...) but in earlier versions it is a copy of some file from under /usr/share/zoneinfo. rpm -q --scripts tzdata does not show any postinstall script, so in the non-symlink versions, how does the copied /etc/localtime file get updated with new zone data? -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS 7.1 user login screen can't scroll up/down
On Thu, Apr 9, 2015 at 10:28 AM, Akemi Yagi amy...@gmail.com wrote: On Thu, Apr 9, 2015 at 8:09 AM, Johnny Hughes joh...@centos.org wrote: On 04/09/2015 09:51 AM, Ole Holm Nielsen wrote: Good point. I never liked the user list anyway. Wonder why the RHEL 7 designers chose to add it? Likely because it is in Fedora and they did not take it out, and it is likely the default from the GNOME project as well. A request to disable the user list filed against RHEL-6 was 'denied': https://bugzilla.redhat.com/show_bug.cgi?id=666220 So, it's not going to change... Kind of crazy that the reason fixing it was denied was that they wouldn't change behavior mid-revision in 6.x. And now it is still not fixed in 7.x, and a mid-rev change actually breaks things even more. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Some subscribers posts to the list ending up in Gmail spam
On Sat, Apr 4, 2015 at 8:35 PM, Nataraj incoming-cen...@rjl.com wrote: On 04/04/2015 09:59 AM, Andrew Holway wrote: Did we work out the technical reason why some users that post to the list are getting dumped into gmail spam? . I believe that if, in your gmail account, you keep marking as NOT SPAM any false positives it will send more of these messages to the right folder. No, I don't think it will ever learn from that,, but there is a way you can set a rule to 'never mark as spam' based on the sender. Which wouldn't be fun on a list with a lot of yahoo.com members. There has been an abundance of discussions in the past about these issues on the various mailman, dmarc and dkim mailing lists as well as in many other places. This whole issue hit the fan early in 2014 when yahoo and aol changed their DMARC policy to reject incoming mail that failed the DMARC test. It was discussed here, I think both before and after the mailman changes were available. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Update only of security vulnerabilities?
On Wed, Apr 8, 2015 at 8:54 AM, Rafał Radecki radecki.ra...@gmail.com wrote: Hi All :) What is the best way to get a list of available security updates? I found several commands for that: 1) yum updateinfo list updates -q --security 2) yum list-security --security -q 3) yum --security check-update -q Based on the sample output below I think I can use any of the three with some awk to get a list of packages. yum updateinfo list updates -q --security FEDORA-EPEL-2014-0525 security libyaml-0.1.5-1.el6.x86_64 FEDORA-EPEL-2014-0990 security libyaml-0.1.6-1.el6.x86_64 yum list-security --security -q FEDORA-EPEL-2014-0525 security libyaml-0.1.5-1.el6.x86_64 FEDORA-EPEL-2014-0990 security libyaml-0.1.6-1.el6.x86_64 yum --security check-update -q libyaml.x86_64 0.1.3-4.el6_6 updates Then I can add this to nagios or cron to get a notification about available security updates. Do you see any advantages/disadvantages in using one of the three choices? There are disadvantages to anything short of keeping your system completely up to date with available updates. How do you do this kind of task? What can you propose to get a notification about available security updates? Most/all updates within a minor version number will be to fix something critical. And the big batches of updates that come at the minor version releases are only tested together. While you can cherry-pick individual package updates to install and in theory they should run and pull in any other updates that are really needed via rpm dependencies, you'll end up running a mix of things that no one else has tried together. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] 6.5 install dvd won't
On Wed, Apr 8, 2015 at 3:24 PM, Chuck Campbell campb...@accelinc.com wrote: When I boot a machine from disc 1 of 2, Centos 6.5 install dvd, I get to a grub prompt. I have no idea what to do from there, but clearly something isn't right. Shoudl I try to download centos 6 again and burn new discs? Yes - 6.6 is available anyway. It is also a reasonable approach to download and install from the 'minimal' iso and then 'yum groupinstall' the package groups you need. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] The future of centos
On Tue, Apr 7, 2015 at 11:32 AM, SilverTip257 silvertip...@gmail.com wrote: On Sat, Apr 4, 2015 at 12:46 PM, Andrew Holway andrew.hol...@gmail.com wrote: In the context of this discussion I would appreciate any feedback the list might have on this article I wrote for my new company. http://otternetworks.de/tech/rhel-centos-brief/ Well put. For a non-technical person, your brief clues them in to the differences between RHEL and CentOS. And the reason both coexist. I do however agree with Valeri in that you probably (c|s)hould mention Debian in there somewhere. I realize you left Debian out because there is no official enterprise support entity as there is with Ubuntu. So at that point, maybe it's not worth mentioning Debian? Seems odd to mention Oracle's name at all in the link without pointing out that they have a product very similar to CentOS with the option to purchase support. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [CentOS-announce] Release for CentOS Linux 7 (1503 ) on x86_64
On Fri, Apr 3, 2015 at 12:19 PM, Always Learning cen...@u64.u22.net wrote: Will Centos versions eventually become incompatible, partially or wholly, with its parent's RHEL versions ? I can understand why that would be commercially advantageous to RH. I think it would be commercially advantageous if they did just the opposite - that is, make it so you could run exactly he same product on all of your machines and pay for support on the ones where you need support. I think that is the way Oracle is handling it. And their download approach makes it pretty clear that you are getting 7.1. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Community voice (was [CentOS-announce] Release for CentOS Linux 7 (1503 ) on x86_64)
On Fri, Apr 3, 2015 at 10:07 AM, Valeri Galtsev galt...@kicp.uchicago.edu wrote: When I start feeling particular distribution does not fill the bill of requirements, I (realizing I will not be able to affect its future route) just start looking for different distribution which is more suitable and will not deflect from being such for some future to come. To this end, I wonder if anyone has gone to the trouble to collect the source for RHEL, CentOS, Oracle, and Scientific Linux (etc.) and diff the whole mess looking for practical and philosophical differences beyond what you can see from their mission statements. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [CentOS-announce] Release for CentOS Linux 7 (1503 ) on x86_64
On Fri, Apr 3, 2015 at 9:33 AM, Lamar Owen lo...@pari.edu wrote: BTW. What happens if a bad ISO gets spun, released and then is replaced in the same month? Does it become: 7.1504_a?; 7.1504b?; 7.1504_1?; 7.150403? Already happened; it had a -01 added. Wiill the directories here: http://vault.centos.org/ going to track that? That is, one per iso release, or one for each minor number with some extra junk tacked on now? -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [CentOS-announce] Release for CentOS Linux 7 (1503 ) on x86_64
On Thu, Apr 2, 2015 at 3:23 PM, Steve Thompson s...@vgersoft.com wrote: On Thu, 2 Apr 2015, Les Mikesell wrote: I didn't see any indication there that you were planning to turn the /etc/redhat-release file into a symlink. In CentOS, /etc/redhat-release has always been a symlink to /etc/centos-release. Well if you define 'always' as 'for CentOS6 and later... So I guess I have redhat-lsb installed on all of my CentOS6 boxes and hadn't noticed that particular breakage before. To be fair, I consider it to be a bug in OCSinventory to not follow a symlink to the contents, but it does point out that any arbitrary change is going to break something that trusted your previous version's functionality. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [CentOS-announce] Release for CentOS Linux 7 (1503 ) on x86_64
On Thu, Apr 2, 2015 at 2:25 PM, Jim Perrin jper...@centos.org wrote: On 04/02/2015 01:28 PM, Phelps, Matthew wrote: Soliciting our feedback *before* changing everything regarding release names would have been nice. We did. http://lists.centos.org/pipermail/centos-devel/2015-February/012873.html I didn't see any indication there that you were planning to turn the /etc/redhat-release file into a symlink. And even if I had I probably wouldn't have thought specifically that it was going to break ocsinventory-ng, although pretty much every unnecessary and arbitrary change breaks something. And besides there's not much reason to think that user comments are ever read on the -devel list. Like this one, for example: http://lists.centos.org/pipermail/centos-devel/2014-June/010940.html -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [CentOS-announce] Release for CentOS Linux 7 (1503 ) on x86_64
On Thu, Apr 2, 2015 at 12:54 AM, John R Pierce pie...@hogranch.com wrote: you guys sure get your panties in a bunch over something as silly as the iso file name. if you don't like the name, rename it... sheesh. I'm not bothered so much by the actual name as by the justification of it having been discussed on the -devel list - where in fact pretty much all of the discussion was that the minor rev number was important and should stay in. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] low latency kernel?
Someone recently posted on the x2go list that he had a problem with jerky videos playing remotely on Ubuntu, but solved it by installing a low latency kernel that was available as an alternative. That made me curious as to whether CentOS has an equivalent - or a way to build something similar. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [CentOS-announce] Release for CentOS Linux 7 (1503 ) on x86_64
On Thu, Apr 2, 2015 at 11:14 AM, Karanbir Singh mail-li...@karan.org wrote: 231 2735 2746 3458 5216 ... I believe your argument works fine since: CentOS-7-x86_64-DVD-1503.iso CentOS-7-x86_64-DVD-1507.iso CentOS-7-x86_64-DVD-1512.iso CentOS-7-x86_64-DVD-1606.iso note, this is YYmm to indicate age, and not serial numbers. But none of us tells us at a glance how these relate to the 'when it is ready' status of the CentOS port of RHEL 7.1. Without additional information I wouldn't know if any/all were done before/after. And I'm curious as to why the reasoning is different for the iso names and the directory in vault.centos.org. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [CentOS-announce] Release for CentOS Linux 7 (1503 ) on x86_64
On Thu, Apr 2, 2015 at 11:41 AM, Johnny Hughes joh...@centos.org wrote: On 04/02/2015 11:30 AM, Alain Péan wrote: Notice that a new minor release includes new drivers for new servers, so it is important to know if you can install at all the system on your server, before any updates ! what does that have to do with an ISO name? How, without a cross reference of some sort, do you know if a given CentOS iso will install on hardware where you know that the needed driver was added in an RH minor rev? -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [CentOS-announce] Release for CentOS Linux 7 (1503 ) on x86_64
On Thu, Apr 2, 2015 at 10:56 AM, Karanbir Singh mail-li...@karan.org wrote: os-release has been at /7/ since the first CentOS 7 release - what extra value does having 7.1 in there bring ? At best it just says that your centos-release rpm has not been updated and/or there is no system level state change that required metadata in that file. If you know that some feature was added or bug fixed in RH 7.1, or more relevant, your boss or security officer or application developer knows that, there is very much value in being able to say that CentOS 7.1-whatever includes the same features/fixes, and that your automated inventory database will show which machines have been updated to that version. Otherwise you'll spend the rest of the day discussing how fix x is done in package-revs-n1 fix y is in package-rev-n2 and how to check for it. Sometimes you need the latter detail, but mostly not, especially for the application guys. Note that any CentOS machine, updated to the same point in time, regardless of where and how it was privisioned should give you the same functional package set. This is an important thing. Yes, but how do you explain that relationship to someone who only has a summary of the RH releases or where the Centos release stands compared to it. For example, what would you have said a few days ago? -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [CentOS-announce] Release for CentOS Linux 7 (1503 ) on x86_64
On Thu, Apr 2, 2015 at 11:51 AM, John R Pierce pie...@hogranch.com wrote: On 4/2/2015 9:49 AM, Les Mikesell wrote: How, without a cross reference of some sort, do you know if a given CentOS iso will install on hardware where you know that the needed driver was added in an RH minor rev? always use the latest one. Which, combined with the possibility of releasing multiples per minor rev and no determinate time frame for the actual initial Centos minor release, really means nothing. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [CentOS-announce] Release for CentOS Linux 7 (1503 ) on x86_64
On Thu, Apr 2, 2015 at 1:08 PM, Johnny Hughes joh...@centos.org wrote: If you really _need_ a specific minor release and want to _stay_ on it, to my knowledge, that's not something CentOS has _ever_ done anyway. You can pay for Red Hat's EUS, or, I think Scientific Linux actually does keep the .y releases separate (but I'm not sure of the details as to how that's implemented). That last paragraph is EXACTLY the message we are trying to put out here. CentOS releases are NOT the same as EUS and have never been .. yet that seems to be what people expect. We want there to be no doubt on this issue. But you are adding more confusion than you resolve if the designation does not indicate that a specified version is 'at least' up to the equivalent of some RH minor rev. Even for the people who might have incorrectly thought is was pinned there. And now there yet another arbitrary difference in what you need to know about one major number vs. another for the long interval they will co-exist. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [CentOS-announce] Release for CentOS Linux 7 (1503 ) on x86_64
On Wed, Apr 1, 2015 at 6:25 AM, Karanbir Singh mail-li...@karan.org wrote: On 04/01/2015 11:45 AM, Александр Кириллов wrote: This was discussed on the CentOS-Devel mailing list and approved by the CentOS Board. It is what we are using in the future. I suggest you become familiar with it. Obviously naming conventions should provide for an easy upstream vendor version reference? does /etc/centos-release-upstream provide you with that ? Are you supposed to download an iso image, install it, then read that file before you know which upstream base minor number you got?In the whole long thread where this naming was supposedly 'discussed', I can't find a single user agreeing that dropping the minor number reference out of the name was a sane thing to do. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [CentOS-announce] Release for CentOS Linux 7 (1503 ) on x86_64
On Wed, Apr 1, 2015 at 11:51 PM, Lamar Owen lo...@pari.edu wrote: I am not so easily confused by the new numbering; what the ISO is named is orthogonal to what it contains, at least in my mind. Adding the date component means CentOS may release more than one iso per RH's minor versions. There isn't much of a consistent relationship between the RH release and the subsequent Centos release other than 'sometime later when it is ready'. So, given a set of Centos isos or even just the most recent, how would you know which RH release it is based on? Download, install, and read the /etc/os-release file before finding out? Or look up some other source of the missing information? -- Les Mikesell lesmikses...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Thanks for 7.1
On Wed, Apr 1, 2015 at 12:43 PM, John R Pierce pie...@hogranch.com wrote: On 4/1/2015 1:39 AM, Karanbir Singh wrote: is it possible that the mirror you are hitting isnt updated as yet ? 'probable' is more likely than 'possible' :) A 'yum clean all' made my systems work yesterday - probably just from picking a different mirror on the next run. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos 7 License???
On Wed, Apr 1, 2015 at 1:17 PM, John R Pierce pie...@hogranch.com wrote: On 4/1/2015 10:56 AM, David A. De Graaf wrote: Is this a cute April Fool joke? If not, WTF is going on? hmm, I wasn't even watching the console of a C7 VM running under esxi, it rebooted in about 10 seconds to 7.1, no such EULA afaik. I thought that was something you only see on the first console login after the install - but it shouldn't repeat after an update. Most of our systems are installed remotely by someone else and managed over ssh after that - so no one is ever going to be at a console to see it. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [CentOS-announce] Release for CentOS Linux 7 (1503 ) on x86_64
On Wed, Apr 1, 2015 at 2:23 PM, Peter pe...@pajamian.dhs.org wrote: My point is that there was a claim by the board that this particular change was discussed extensively on the -devel list. If it was then it should be quite easy to point out the post(s) in the archives where this particular discussion tool place. The addition of a date reference makes sense to allow and identify respins within the life of a minor rev, but... There were alternatives proposed, like: http://lists.centos.org/pipermail/centos-devel/2014-June/010940.html but I can't see any 'discussion' about why the weird concept of using the minor .0 in the initial iso name but dropping it out of subsequent versions was better or chosen. I see the directory created on vault.centos.org is surprisingly sane, though, retaining the useful minor rev number. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Building a newer glibc RPM for CentOS 6 and installing into an alternate path
On Mon, Mar 30, 2015 at 9:47 PM, Alfred von Campe alf...@von-campe.com wrote: Tell your vendor you want a centos 6 version of the library, it's really not a huge ask, esp if you are paying them. If they say no, do a new install of centos 7 and run it on a different box. It's the only reasonable thing to do, and if you do anything else and make anyone else support it, you are a bad person. I’m not quite ready to move to CentOS 7 yet. I would have to upgrade about 80 desktops, a couple of dozen VMs, and a handful of servers. That’s after some extensive testing to make sure all our applications and cross compilers run on CentOS 7. I realize the dependency hell a newer version of glib would cause, but I want to at least try it. Isn't this the problem that docker was invented to solve? Forget I ever said I wanted to replace glibc. Assume it’s a different library or application. I guess what I really need to know is how to rebuild a source RPM after modifying the installation path. A quick peek at the spec file for glibc did not reveal any easy options, but then again I don’t really speak the RPM spec file language. If you build a stock rpm - or just grab an existing binary rpm you can install the files in a different location with: cd /some/location rpm2cpio some_package.rpm | cpio -idmv --no-absolute-filenames (that's sort of routine for debugging cores from a different system) But I'd expect some close coupling between the compiler and glibc too, so you probably can't compile a new version either without installing newer tools too. What kind of application is this? Would it be practical to run it remotely via ssh or a remote X window so you would only need one or a few systems capable of running it? -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Building a newer glibc RPM for CentOS 6 and installing into an alternate path
On Tue, Mar 31, 2015 at 1:21 PM, m.r...@5-cent.us wrote: Perhaps, but I’m running CentOS 6.6 i686 (i.e., 32-bit), and it appears that Docker requires 64-bit. Oh well, I was getting my hopes up for a while. snip I haven't really been following this thread closely, but would it be a dumb question to suggest installing the rpm with the relocate flag, and then use LD_LIBRARY_PATH? It was mentioned earlier that LD_LIBRARY_PATH doesn't work with libc, but LD_PRELOAD should.. I tried unpacking a centos7 glibc rpm under /tmp/c7libs on a centos 6 box and trying to run a centos7 version of cat with: LD_LIBRARY_PATH=/tmp/c7libs/lib64:$LD_LIBRARY_PATH LD_PRELOAD=/tmp/c7libs/lib64/ld-linux-x86-64.so.2 /tmp/c7libs/lib64/libc.so.6 /tmp/cat-7 /tmp/test seems to work, but that's not a real demanding test... -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] emailing plain text to exchange/outlook
I know this isn't CentOS-specific, but it is probably a common problem - does anyone have a solution? If you mail something that is plain text from linux a recipient using outlook, it will remove line breaks more or less randomly. There is a way to tell outook to put them back as you read each message, but most people just think I sent it wrong. Is there something you can do to make a plain text list show up correctly short of converting it to html with br's? -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Building a newer glibc RPM for CentOS 6 and installing into an alternate path
On Tue, Mar 31, 2015 at 12:43 PM, Alfred von Campe alf...@von-campe.com wrote: On Mar 31, 2015, at 12:21, Jim Perrin jper...@centos.org wrote: Isn't this the problem that docker was invented to solve? Yes, you could address this with docker quite easily, depending on the app. Perhaps, but I’m running CentOS 6.6 i686 (i.e., 32-bit), and it appears that Docker requires 64-bit. Oh well, I was getting my hopes up for a while. In the mean time, we’ve requested a CentOS 6 compatible .shared library from our vendor, and I’m keeping my fingers crossed while waiting for their reply. What about remote exectution? You might even give it access to local files with x2go. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] viewvc for EL7?
Is there a reliable repo with viewvc for Centos7? Or some reason it isn't in EPEL? -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Netflix
On Thu, Mar 26, 2015 at 8:41 PM, Bob Hepple bob.hep...@gmail.com wrote: Now that netflix is in Australia, I wouldn't mind giving it a burl. It's working fine on my fedora-21 lappy with chrome-40 but not on our centos-6 mythtv setup even with chrome-41. I understand the difference might be the version of NSS - fedora-21 has 3.17 while centos is stuck at 3.16. Other than that, I'm flumoxed. Anyone got netflix running on centos-6? The Ubuntu or Mint distos are probably the least painful path to facebook/chrome on 32 bit hardware. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Not getting updates?
On Fri, Mar 27, 2015 at 2:30 PM, Mark Haney mark.ha...@vifprogram.com wrote: I have no excludes in yum.conf. But I noticed something odd in the CentOS-Base.repo file. The [updates] section didn't have an explicit 'enabled=1' in it. Though, when I added it in, it made no difference. I have noticed that I do have some updated packages (like httpd) that are from February and appear to be the most recent based on the mirrors, but every mirror I hit I see no updated packages listed for this month. Maybe there's just not been any and I'm overreacting. I think all of the current work is being held in the cr repo while they are scrambling to get a full 7.1 release completed. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Not getting updates?
On Fri, Mar 27, 2015 at 1:45 PM, Mark Haney mark.ha...@vifprogram.com wrote: I installed CentOS 7 late last year to use as my Nagios/Cacti Monitoring server. Clean install, nothing real complicated just the server version with no GUI, just command line/SSH. I have noticed over the last 3 months that I've not had ANY updates when I run 'yum update'. I have run 'yum clean all' to see if that might be a problem, and I've made sure the updates repo is enabled (it is), but I'm getting no CentOS updates. Did something change that I'm not aware of? I'm even clueless how to being debugging this. I'm no noob to RPM based systems as I run Fedora pretty much everywhere else. Ideas? Try something like yum info kernel. It should show the repos it is checking, the installed version and the repo it is from, plus available newer versions. If your installed version isn't from anaconda, maybe you have automatic updates enabled and there is nothing newer when you check. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Not getting updates?
On Fri, Mar 27, 2015 at 3:43 PM, John R Pierce pie...@hogranch.com wrote: On 3/27/2015 1:27 PM, Fred Smith wrote: oh. is /7/ supposed to be a symlink to /7.0.1406/ or a separate directory ? it appears my mirroring of the mirror may be broken if its supposed to be a symlink. in /7.0.1406/, I'm seeing files up to Feb 22. /7/ is a link to the latest release, which at this point in timeis 7.0.1406. Once 7.1 is released, the 7 symlink will point to it. ah, then my mirroring is broken. I thought Centos repos always worked that way - mostly so the mirrors only had to hold the updates for the latest release, whatever that might be. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] MATE desktop dependency?
On Thu, Mar 26, 2015 at 4:41 PM, Richard lists-cen...@listmail.innovate.net wrote: Thanks, but it doesn't help to --enablerepo=epel-testing. The libgtop2 package should be from the base repo anyway. Sorry, just checked. It looks to be in cr. So... the right thing to do for someone who just wants to update a system today would be??? Probably depends on your view of CR. Here's the announcement for it the other day: http://lists.centos.org/pipermail/centos-announce/2015-March/020980.html I updated a machine the other day with a combination of CR and epel-testing (key MATE things were there still) and it seems fine, though I haven't tested it heavily yet. The epel things that were in -testing may have moved to epel base by now. It's not so much a matter of having a view of CR as that I didn't expect things to appear in EPEL that depend on base versions that aren't in general release yet. Is that intentional, and don't some number of people have to approve something before it gets out of epel-testing? Does everyone else have cr enabled? -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] MATE desktop dependency?
On Thu, Mar 26, 2015 at 4:53 PM, Johnny Hughes joh...@centos.org wrote: It's not so much a matter of having a view of CR as that I didn't expect things to appear in EPEL that depend on base versions that aren't in general release yet. Is that intentional, and don't some number of people have to approve something before it gets out of epel-testing? Does everyone else have cr enabled? See my other post to this list. EPEL is written for and built against RHEL, which is on 7.1. You will either have to wait until we release our 7.1, use CR or buy RHEL. That makes sense - but it also makes it an ongoing issue for Centos users to expect. It's not a serious problem for me, but it would be a bad first experience with CentOS if someone tries to install a system with MATE Desktop today. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] MATE desktop dependency?
Does anyone know what's up with: Error: Package: marco-1.8.3-1.el7.x86_64 (epel) Requires: libgtop-2.0.so.10()(64bit) Isn't the EPEL package built against stock Centos? -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] MATE desktop dependency?
On Thu, Mar 26, 2015 at 4:09 PM, Richard lists-cen...@listmail.innovate.net wrote: Does anyone know what's up with: Error: Package: marco-1.8.3-1.el7.x86_64 (epel) Requires: libgtop-2.0.so.10()(64bit) Isn't the EPEL package built against stock Centos? Check epel-testing, that's where it (still) was a few days ago I believe. [I don't have my C7 laptop on so can't confirm things quickly.] Thanks, but it doesn't help to --enablerepo=epel-testing. The libgtop2 package should be from the base repo anyway. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] MATE desktop dependency?
On Thu, Mar 26, 2015 at 4:27 PM, Richard lists-cen...@listmail.innovate.net wrote: Original Message Date: Thursday, March 26, 2015 16:18:45 -0500 From: Les Mikesell lesmikes...@gmail.com To: CentOS mailing list centos@centos.org Cc: Subject: Re: [CentOS] MATE desktop dependency? On Thu, Mar 26, 2015 at 4:09 PM, Richard lists-cen...@listmail.innovate.net wrote: Does anyone know what's up with: Error: Package: marco-1.8.3-1.el7.x86_64 (epel) Requires: libgtop-2.0.so.10()(64bit) Isn't the EPEL package built against stock Centos? Check epel-testing, that's where it (still) was a few days ago I believe. [I don't have my C7 laptop on so can't confirm things quickly.] Thanks, but it doesn't help to --enablerepo=epel-testing. The libgtop2 package should be from the base repo anyway. Sorry, just checked. It looks to be in cr. So... the right thing to do for someone who just wants to update a system today would be??? -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] leap second and Centos
On Wed, Mar 25, 2015 at 7:41 AM, Tris Hoar trish...@bgfl.org wrote: On 24/03/2015 18:54, Les Mikesell wrote: On Tue, Mar 24, 2015 at 1:26 PM, Frank Cox thea...@melvilletheatre.com wrote: On Tue, 24 Mar 2015 12:56:27 -0500 Les Mikesell wrote: Doesn't anyone have a list of the oldest kernel version for each Centos version you could be running and still avoid known problems? https://access.redhat.com/labs/leapsecond/leap_vulnerability.sh If you don't have a subscription then the key bits from the script are: # RHEL 4 needs to be after -89 # RHEL 5 needs to be after -164 # RHEL 6 Affected Versions # 6 GA: All Versions # 6.1: Versions before -131.30.2 # 6.2: Versions before -220.25.1 # 6.3: Versions before -279.5.2 and that the tzdata should be from 2015 Thank you. That may save dealing with at least a few change request forms and scheduling procedures. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] leap second and Centos
On Tue, Mar 24, 2015 at 1:26 PM, Frank Cox thea...@melvilletheatre.com wrote: On Tue, 24 Mar 2015 12:56:27 -0500 Les Mikesell wrote: Doesn't anyone have a list of the oldest kernel version for each Centos version you could be running and still avoid known problems? The best answer to your question is the latest version, since previous versions all have known issues of one kind or another. It's not a great idea to run outdated Centos systems with known bugs of any kind. I can't argue with that (then again, you were running that buggy code before and happy with it), but having to reboot frequently is not ideal either, particularly on machines where scheduling downtime is a fairly involved process. I'm looking for the compromise with the least pain involved. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] leap second and Centos
On Wed, Mar 18, 2015 at 6:30 PM, Akemi Yagi amy...@gmail.com wrote: On Fri, Mar 6, 2015 at 2:04 PM, Gordon Messmer gordon.mess...@gmail.com wrote: On 03/06/2015 01:41 PM, Les Mikesell wrote: I just want the package revisions for at least the kernel and tzdata* files and anything else where previously-found bugs related to the leap second have been fixed. https://access.redhat.com/articles/15145 In addition to that article, the following one was updated recently: https://access.redhat.com/articles/199563 (Are we susceptible to a leap second event?) Still way tl;dnr material. Doesn't anyone have a list of the oldest kernel version for each Centos version you could be running and still avoid known problems? -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Facebook CentOS group close to 15.000 members!
On Mon, Mar 23, 2015 at 8:53 AM, James B. Byrne byrn...@harte-lyne.ca wrote: On Mon, March 23, 2015 05:24, Nux! wrote: I find this very, very sad. I find it unsavoury. We are recommending that acknowledged newbies subscribe to a service known for repeatedly and persistently violating its members' privacy? There is a real simple answer to privacy on facebook. Just don't post anything there that you would not want to be public. Just like this mail list. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Chromium browser for C6
On Mon, Mar 16, 2015 at 10:08 AM, Johnny Hughes joh...@centos.org wrote: On 03/16/2015 09:38 AM, Phelps, Matthew wrote: Johnny, Should we give up hope on this issue? After 7.1 is released, I will try again to get permission to do this. I am not giving up hope, just working with legal issues is quite a PITA. But, I personally work try to move to EL7 for machines needing chrome, as the one directly from google currently works. What is it that is actually missing in CentOS6? Would it be stuff that is already available in the devtoolset SCL's - or would build under that? If that would work, why fight with other ways of doing it? -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos 6 - Persistant static routes
On Thu, Mar 12, 2015 at 2:25 PM, Warren Young w...@etr-usa.com wrote: On Mar 12, 2015, at 11:52 AM, Jason Warr ja...@warr.net wrote: On Thu, 12 Mar 2015 12:43:27 -0500, Robert Moskowitz r...@htt-consult.com wrote: I found: http://www.cyberciti.biz/tips/configuring-static-routes-in-debian-or-red-hat-linux-systems.html where it says to add to ifcfg-eth0: 192.168.128.0/17 via 40.53.24.3 That’s only for RHEL 7: http://goo.gl/AtjIyI Aside from being irritating, that's just wrong. I'm using that syntax on Centos5, ADDRESS0=192.168.128.0 NETMASK0=255.255.128.0 GATEWAY0=40.53.24.3 This is the scheme used in prior versions of RHEL. I think both types of syntax will work in all versions. The GUI tools do the latter form. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos 6 - Persistant static routes
On Thu, Mar 12, 2015 at 3:01 PM, Robert Moskowitz r...@htt-consult.com wrote: where it says to add to ifcfg-eth0: 192.168.128.0/17 via 40.53.24.3 That’s only for RHEL 7: http://goo.gl/AtjIyI Aside from being irritating, that's just wrong. I'm using that syntax on Centos5, AH, I think I see what I did wrong. I put that line in the ifcfg-eth0 when according to this page, it goes in the route-eth0 just like the old format. I will give that a try tomorrow... Yes, I missed that part. You can put a default gateway in the ifcfg- file with GATEWAY= but if you have more than one NIC you should only have one GATEWAY= entry for the NIC facing that router, and any routes in a route-xxx file should be through a router where the next hop specified is reachable though the xxx-named interface. The routes are added as the interfaces are brought up and will fail if the gateway specified isn't reachable - as might happen if they need to go through an interface that isn't up yet. If you only have one interface you don't have to worry about that - the default GATEWAY= can be in ifcfg-eth0 and the static route(s) through a different router on the same subnet go in route-eth0. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos 6 - Persistant static routes
On Thu, Mar 12, 2015 at 3:16 PM, Robert Moskowitz r...@htt-consult.com wrote: What I really need to do is get RIP working on that router and get my servers to listen to RIP... One leap at a time! The usual quick-fix in a small network is to make your default router know about everything else. That is, your internet-facing router knows the route to your internal router - and vice versa. Then if you send to a single default and have a destination address that the other router on the same network should handle, it will forward the packet for you _and_ send you an icmp redirect telling you that it will save time if you send to the other router yourself. That way the computers don't have to participate in real routing protocols. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] SquidAnalyzer: minor trouble building RPM
On Wed, Mar 11, 2015 at 7:37 AM, Niki Kovacs i...@microlinux.fr wrote: After this heated exchange, I decided to take a pragmatic approach and choose a more appropriate tool as a base for my business. So here I am. Yeah, businesses have this weird idea that if something works right, it should just keep working for the life of the business... By the way - if you are new to Centos and RH-style in general, you might want to look at how much of the local configuration settings are abstracted into files under /etc/sysconfig/. I'm not sure if slackware used that at all since it is a SysVinit concept - or how it will evolve with the change do systemd, but generally for the packages that pick up option settings there you can avoid editing the main config files and setting up conflicts with future rpm updates. It's not perfect but it helps. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Glibc sources?
On Wed, Mar 11, 2015 at 1:34 PM, ANDY KENNEDY andy.kenn...@adtran.com wrote: De-ignorant me please: How does one discern the package name EPEL from mock? Oh, never mind. I see this is some add-on repo site. Like I said, a little light will do :). It's not just 'some' third party repo - it has stuff pretty much everyone needs and has a policy of not overwriting any core packages so it is generally safe to leave enabled. yum install http://mirror.cogentco.com/pub/linux/epel/6/i386/epel-release-6-8.noarch.rpm yum install mock (If you are on Centos 5, you'd have to wget the release rpm and install with rpm). -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Glibc sources?
On Tue, Mar 10, 2015 at 5:47 PM, ANDY KENNEDY andy.kenn...@adtran.com wrote: How do I tell rpmbuild to build the i686 version of the library in place of the x86_64? I've done some looking around on the web and I have found something about: setarch i686 mock -r something ... rebuild my.rpm Not being able to find the mock package for CentOS, I thought maybe: ??? Mock is in EPEL. setarch i686 rpmbuild -ba glibc.spec If you repackaged the source rpm you should be able to: mock -r epel-6-i386 --rebuild glibc-xxx.srpm -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos 6 - disabling IPv6 addressing
On Mon, Mar 9, 2015 at 12:39 PM, Robert Moskowitz r...@htt-consult.com wrote: I have to disagree on that. NATs is the problem and I am one of the causes of that problem as one of the principals behind RFC 1918. What has happened is that HTTP has become the transport for the Internet. Very bad in a number of ways. On the contrary. NAT and HTTP are the reasons most households are connected. But now we have http 2.0 to provide some pretense of security. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] leap second and Centos
On Fri, Mar 6, 2015 at 4:04 PM, Gordon Messmer gordon.mess...@gmail.com wrote: On 03/06/2015 01:41 PM, Les Mikesell wrote: I just want the package revisions for at least the kernel and tzdata* files and anything else where previously-found bugs related to the leap second have been fixed. https://access.redhat.com/articles/15145 https://rhn.redhat.com/errata/RHSA-2013-0496.html Helpful, but not exactly concise... And I don't understand the concept of /usr/share/zoneinfo/right/*. Are those supposed to print the right time if your clock is left wrong? Contrary to your previous assertion, in 2012, it was not the kernel that consumed CPU cycles. That problem was seen in user space. But it is just as much the kernel's fault if it returns from nanosleep()/usleep() instantly without counting any time down so you spin in user space as if stayed in the kernel. Nothing in user space could have fixed it. The problem was fixed by changing the kernel's implementation of leap second handling, but the reason that you are being told that testing your applications is the only way to verify that there is not a problem is that these problems aren't confined to the kernel and tzdata packages. Unknown problems can happen anywhere/any time. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] leap second and Centos
On Tue, Jan 20, 2015 at 3:27 PM, Michael Hennebry henne...@web.cs.ndsu.nodak.edu wrote: Unix and ntp handle leap seconds a bit differently. Unix time increases during the leap second and drops back a second after. Ntp freezes time during the leap second. OS kernels may do either or neither. Does anyone have a succinct summary of how to prove to management-types that a given linux box won't have a problem with the leap second? Like kernel some_version, tzdata some_version, tzdata-java some_version? -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Squid on CentOS 7: few questions
2015-03-06 12:29 GMT-06:00 Niki Kovacs i...@microlinux.fr: I recently migrated my office's server from Slackware64 14.1 to CentOS 7. Right now I'm in the process of configuring the Squid web proxy. I edited the default /etc/squid/squid.conf, and here's what I have so far: --8-- # /etc/squid/squid.conf # Nom d'hôte du serveur Squid visible_hostname amandine.microlinux.lan # Définitions acl localnet src 192.168.2.0/24 # RFC1918 possible internal network acl SSL_ports port 443 acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 # https acl Safe_ports port 70 # gopher acl Safe_ports port 210 # wais acl Safe_ports port 1025-65535 # unregistered ports acl Safe_ports port 280 # http-mgmt acl Safe_ports port 488 # gss-http acl Safe_ports port 591 # filemaker acl Safe_ports port 777 # multiling http acl CONNECT method CONNECT # Règles d'accès http_access deny !Safe_ports http_access deny CONNECT !SSL_ports http_access allow localnet # Port du proxy http_port 3128 # Taille du cache dans la RAM cache_mem 256 MB # Vidage système coredump_dir /var/spool/squid # Durée de vie des fichiers sans date d'expiration refresh_pattern ^ftp: 144020% 10080 refresh_pattern ^gopher:14400% 1440 refresh_pattern -i (/cgi-bin/|\?) 0 0% 0 refresh_pattern . 0 --8-- The proxy is working as expected. I have a few questions for fine-tuning though. 1. Squid's main logs are stored in /var/log/squid/access.log. I'd like to setup logfile rotation for that, since it can become quite big. How do you handle this? With Squid's intern 'logfile_rotate' directive or with logrotate? What I'd like to do is rotate this logfile about once a week. The rpm should have configured logrotate: rpm -q --list squid |grep logrotate will show where the config file lands. 2. Which user is Squid supposed to run as under CentOS? On my Slackware server I had the following: cache_effective_user nobody cache_effective_group nobody What's an orthodox setting for CentOS? The rpm should have created the squid user and group: rpm -q --scripts squid will show what it ran to do that. 3. The access rules are a bit minimal. Do they seem OK to you for a LAN? Any suggestions? Unless you want to restrict outbound access, the main thing is the acl to permit access from your local network source addresses (and no others). I'd recommend an external firewall or at least iptables blocking inbound internet access to port 3128 also. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] leap second and Centos
On Fri, Mar 6, 2015 at 12:52 PM, Chris Adams li...@cmadams.net wrote: Once upon a time, Les Mikesell lesmikes...@gmail.com said: Does anyone have a succinct summary of how to prove to management-types that a given linux box won't have a problem with the leap second? Like kernel some_version, tzdata some_version, tzdata-java some_version? Only way to prove it is to set up a test and try it. I don't think I need to 'prove' that computer programs do repeatable things. I just want to know the version numbers that need to be installed - something relatively easy to check. AFAIK there are no known issues with an up-to-date system, Yeah, but you probably would have said that before the 2012 instance too... And what I really want to know is how 'out-of-date' a system can be. but that was also true at the last couple of leap seconds (the issues that happened were previously unknown). Now we know the issues, and hopefully someone had done the simulation tests. I just want to know the specific kernel and package versions that have the fixes. But none of the links I've found discussing the issues boil it down to something a non-geek would want to see. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] leap second and Centos
On Fri, Mar 6, 2015 at 1:50 PM, m.r...@5-cent.us wrote: I don't think I need to 'prove' that computer programs do repeatable things. I just want to know the version numbers that need to be installed - something relatively easy to check. snip Two other thoughts: first, that it worked perfectly fine the last leap second, and second, that ntpd, according to the manpage, can and will adjust for seconds of difference with no problem at all, since that's it's job. Errr, no. It did _not_ work fine in the last leap second. If you run threaded applications (including, but not exclusively, java) or applications that called usleep the kernel would spin with 100% CPU use until you reset the date with some means other than ntp. How could you have missed that: http://www.wired.com/2012/07/leap-second-bug-wreaks-havoc-with-java-linux/. Every other sysadmin in the world got calls in the middle of the night to fix their servers. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] leap second and Centos
On Fri, Mar 6, 2015 at 2:26 PM, m.r...@5-cent.us wrote: Every other sysadmin in the world got calls in the middle of the night to fix their servers. Ah, the system was fine, it was java that failed. And we've got a few tomcat apps... but IIRC, we fixed them the next day - we're tier 3, and so not critical, and could do that. No, it was _not_ java that failed. The kernel was spinning instead of scheduling threads. Any threaded application would have triggered the kernel bug - or a usleep() call from a non-threaded application. By the time I got the call I was able to google the fix about resetting the date, but the guys who manage some SuSE systems started earlier and ended up rebooting some of them - and they don't run java applications. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] leap second and Centos
On Fri, Mar 6, 2015 at 2:45 PM, Chris Adams li...@cmadams.net wrote: So again, if you want to make sure there's no new issue, you'll have to set up a test yourself. I doubt the 2008 or 2012 issues will happen again, but there's plenty of room for new issues. So are you saying that you think no one upstream has done any testing yet? Or that I should have better resources for testing than they do? I was hoping things weren't really that bad and that I just hadn't found the simple summary of results yet. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] leap second and Centos
On Fri, Mar 6, 2015 at 3:15 PM, Chris Adams li...@cmadams.net wrote: Short answer: last time it was threaded stuff like Java, the time before it was systems under heavy kernel loads. Who knows, this time Postfix could hang, or MySQL could corrupt databases, or something else. Probably nothing will happen, but if you want a cover your ass report, I don't think anybody has done that. I'm not looking for a research project on how to prove that the last bug has been found or not. And I'm not particularly concerned about application-level bugs. Every time a second rolls over we take a chance of hitting a new previously unknown bug. We're all taking that chance. I just want the package revisions for at least the kernel and tzdata* files and anything else where previously-found bugs related to the leap second have been fixed.What I want to know (and be able to describe concisely to a non-geek person) is that on a particular machine either that the known/expected bugs have been fixed, or that they haven't and we need to schedule a reboot. And it seems like something everyone else using a distribution would want to know as well, at least for machines where scheduling a reboot is no-trivial. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] grsync for centos 7
On Thu, Mar 5, 2015 at 4:30 PM, Francis Gerund ranr...@gmail.com wrote: 3) I hate having to re-do #2 every time I want to do a small ad-hoc backup or synchronization, let alone a full filesystem backup. If you are doing system backups regularly with manual command line runs, I'd recommend looking at backuppc (well I'd recommend it even more if you aren't doing regular backups...). But it works best with a 2nd system doing the work and might not be a replacement for rsync to a removable drive. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] grsync for centos 7
On Thu, Mar 5, 2015 at 11:44 AM, Francis Gerund ranr...@gmail.com wrote: Hello. I think it is just too easy to make mistakes with rsync. And getting it almost correct can really get you hurt. What are you trying to do, and what kind of mistakes are you worried about? The only things I find confusing are what the trailing / means on a directory name and that -H isn't bundled with the other options that -a includes that you normally want.You can avoid the ambiguity of whether the top directory or just the contents will be copied by cd'ing into the source directory and doing: rsync -av . host:/path/to/dir. That is, by using '.' as the source you can't mistakenly create another directory level on the target. And you just have to remember that it will create the final directory in the target path if it doesn't exist, but just the final one, not the whole path. And if you add -n or --dry-run to the options along with -v, it will go through the motions and show you the files that would be transferred without actually doing it. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Networking troubles on CentOS 7
On Thu, Mar 5, 2015 at 10:02 PM, Kashyap Bhatt thekashy...@yahoo.co.in wrote: Hi, I've been trying to get networking up and running on CentOS 7 in a VMWare (5.5) VM. From inside the machine (connected to console (GNOME desktop)) it looks like network is up. From outside I can't reach it. Are you sure the vmware NIC is configured as bridged, not NAT on the host side? -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] selinux allow FTP
On Mon, Mar 2, 2015 at 4:43 PM, Tim Dunphy bluethu...@gmail.com wrote: errr, I meant, sftp, not rscp Heh.. yeah. But the client isn't gonna go for that. LOL. Any way to allow regular ol' FTP using SELinux? Or does that just defeat the purpose of having a secure SELlinux server entirely? What is the context here? The big problem with ftp is that it passes the user credentials in the clear. There is nothing particularly wrong with an anonymous ftp download area where the files are put in place with something more secure - but it is usually easier to use http for that and you'll have less trouble with firewalls. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Kickstart with multiple eth devices
On Wed, Feb 25, 2015 at 4:45 PM, Ashley M. Kirchner ash...@pcraft.com wrote: Out of order meaning, it puts the additional ethernet card as eth0, with the built-in ports as eth1 and eth2 respectively. WITHOUT the additional card installed, it puts the built-in ports as eth0 and eth1, which is what I want it to do. The additional card should be eth2, at least that's what I want it to do. Looking at persistent-net.rules, it always puts the additional card first, both without your script as well as with. I need it to be last. The system's built-ins should always be eth0 and eth1 respectively. How can you confirm 'always' here? I haven't done it in the context of PXE booting, but I see random ordering of cards and motherboard nics on first installs with Centos6.x That is, the nics on the motherboard and on each card will have adjacent numbers but the cards and motherboard sets jump around until the MAC addresses are recorded in the etc/udev/rules.d/70-persistent-net.rules to nail them down. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] lua-debuginfo for CentOS6?
Is there some reason http://debuginfo.centos.org/6/x86_64/ is missing a lua-debuginfo package? The /5/ and /7/ sections have it. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] how to stop yum when networkmanager has broken resolv.conf?
So, I'm getting an error where the network service and NetworkManager apparently don't agree on how to bring up vlans on bonded nics. Things come up if you 'ifup ..' manually. I thought I'd check if there were any updates, forgetting to fix what NetworkManger had done to /etc/resolv.conf and: http://centos.arvixe.com/7.0.1406/os/x86_64/repodata/repomd.xml: [Errno 12] Timeout on http://centos.arvixe.com/7.0.1406/os/x86_64/repodata/repomd.xml: (28, 'Resolving timed out after 30381 milliseconds') Trying other mirror. ^C^C^C ^C^C^C Current download cancelled, interrupt (ctrl-c) again within two seconds to exit. Yeah - I did hit it about 6 times there. What do you have to do to make it actually stop in some reasonable amount of time? -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
