Re: [CentOS] Upstream and downstream (was Re: What are the differences between systemd and non-systemd Linux distros?)
On Fri Oct 19 00:52:12 UTC 2018 Japheth Cleaver wrote: > This brings to mind a video I was pointed to not long ago of Brendan > Conoboy's talk at a Dojo recently: > > https://www.youtube.com/watch?v=HQsUdLPJW20 Hey, that's me! Hi. By the way, Jim Perrin did an updated version of this talk *today* at CERN in my absence (thanks Jim!). Hopefully the video will be posted soon. I expect we'll be doing updated versions of these at Devconf, future Dojos, etc- as things progress. > For quite a long time, many (perhaps most) folks had assumed that > Fedora functioned more or less directly as the internal alpha for > RHEL, with a branch at some point occurring, followed by pruning > of packages, hardening, vendor testing, and release. This is roughly true for new releases (plus or minus the kernel), but not for subsequent minor release updates. It is a shame because so much great work happens in Fedora between major RHEL releases. > Subsequently, > CentOS (even after the RH integration) functioned *strictly* as a > clean-room downstream rebuild, with the ability to do unsupported > things, like alternate architectures, or heavier kernels, restricted > to what could be done while maintaining a 100% binary compatible > rebuild. Any contributions back up where taken to be incidental, > from CentOS users reporting bugs that could be verified against RHEL. > > Conoboy, on the other hand, takes great pains during the speech to > describe a much more fluid and complex interaction between CentOS > and its upstream, and puts forth CentOS as a mechanism (perhaps > the best mechanism) for the winder EL community to contribute > (something?) back into RHEL's future. He also gives clear signals > that various Fedora steps have been in directions that Red Hat did > not want EL necessarily going, and that the simplistic assumptions > we've commonly been making aren't really correct. You might be reading into this more than is there. It's not so much that things are fluid as it is that they are undefined. There is no clear, consistent way for a member of the Fedora or CentOS communities, who create something great, to have that thing make its way into an update of an existing RHEL major release. Defining that path, making it possible, would be win for all. > Obviously, there seems to be a bit of a discrepancy there. > > The wider EL community is trapped between a rock and a hard place > somewhat. If you try to direct Fedora into the needs of EL users, > you stand a good chance of getting told to pound stand, and that > EL is getting in the way of bleeding-edge progress. Traditionally, > CentOS has had its hands tied since it aims to be 100% compatible > with upstream. Red Hat (and Red-Hat-as-a-sponsor-of-CentOS) might > do well to clarify just what type of back-and-forth it wants out of > the wider EL-using community. Does it want direct feedback in the > form of tickets? Should people form SIGs? Obviously RHEL7 is not > changing init systems, but where should one talk about the future? Man, it breaks my heart when I read things like this. There might be some historic truth to the above, but it doesn't have to be the future. The objective I mentioned near the end of the talk has been posted, but not yet voted on: https://fedoraproject.org/wiki/User:Pfrields/Lifecycle_Objective The beauty of community is that it can grow and shift according to the needs of its members. To me it looks like the lifecycle objective may be a partial answer to how Fedora, RHEL, and CentOS communities can reach a state of fluidity, a virtuous cycle. The thing that makes it the most likely to succeed is if members of the Fedora, RHEL, and CentOS communities work on it together. I hope those reading this who are interested in that join in. -- Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] What are the differences between systemd and non-systemd Linux distros?
> Am 20.10.2018 um 00:11 schrieb Paul Heinlein : > > On Fri, 19 Oct 2018, mark wrote: > >> Yeah. I have trouble finding the actual startup configs - >> /etc/systemd/system? /var/lib? whereeverthehell they are, do a locate as >> opposed to /etc/init.d to find the damn name (nfs? nfsd? idmapd? nfs-idmapd? >> rpc-idmapd?) > > systemctl status <> > > E.g., > > [~]$ systemctl status ntpd > ● ntpd.service - Network Time Service > Loaded: loaded (/usr/lib/systemd/system/ntpd.service; enabled; vendor > preset: disabled) > > It shows the definition file. > Unit File Load Path https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Unit%20File%20Load%20Path -- LD ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] What are the differences between systemd and non-systemd Linux distros?
On Fri, 19 Oct 2018, mark wrote: Yeah. I have trouble finding the actual startup configs - /etc/systemd/system? /var/lib? whereeverthehell they are, do a locate as opposed to /etc/init.d to find the damn name (nfs? nfsd? idmapd? nfs-idmapd? rpc-idmapd?) systemctl status <> E.g., [~]$ systemctl status ntpd ● ntpd.service - Network Time Service Loaded: loaded (/usr/lib/systemd/system/ntpd.service; enabled; vendor preset: disabled) It shows the definition file. -- Paul Heinlein <> heinl...@madboa.com <> https://www.madboa.com/ ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Future Releases
On Fri, Oct 19, 2018 at 10:15 PM Robert Moskowitz wrote: > > Yeah, I was kind of hedging my comment that maybe something for 1.3 > would be in the earlier version, but yes, all the TLS 1.3 work was > focused on openSSL 1.1.1. I was personally focused on EDDSA support. > > So a number of items have to appear in C6 for it to support TLS 1.3. > More slowness in TLS 1.3 availability. Kind of flies in the face of a > claim made against my HIP protocol which 'requires kernel level changes' > and thus too hard to deploy. TLS is an upper layer protocol and changes > easily roll out. > > Yeah, right. > > Keep in mind that first version of RHEL 6 was released 8 years ago and since May 2017 is in Maintenance Level 2, that means: Software Enhancements = No more info here https://access.redhat.com/support/policy/updates/errata/ Coming to the particular question of OpenSSL, originally was released with 1.0.0 in RHEL 6, then rebased to 1.0.1e in 2013 with RH EL 6.5 (but when still in Full Support phase). Here are interesting discussions and articles you can access without Red Hat login: https://access.redhat.com/discussions/3440141 and https://access.redhat.com/discussions/2172641 and https://access.redhat.com/articles/1462223 And CentOS follows in cascade Gianluca ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] No searchable archives for this mailing list?
On Oct 19, 2018, at 2:13 PM, Kay Schenk wrote: > > I can't seem to find a way to search the archives of this list Here’s one: https://www.mail-archive.com/centos@centos.org/ Alternately, use the “site:” feature of your search engine to restrict it to the web archives of this list: https://duckduckgo.com/?q=systemd+site%3Alists.centos.org%2Fpipermail%2Fcentos ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] systemd automount of cifs share hangs
> > But if I start the automount unit and ls the mount point, the shell hangs > and eventually, a long time later (I haven't timed it, maybe an hour), I > eventually get a prompt again. Control-C won't interrupt it. I can still > ssh in and get another session so it's just the process that's accessing > the mount point that hangs. > I don't have a solution, but I wanted to point out this same hang happened to me recently with a Myricom 10Gb card. Apparently Myricom drivers do not support CentOS 7 smb connections, although HTTP traffic works fine. I solved it by switching to a different NIC. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Future Releases
On 10/18/18 11:06 PM, Barry Brimer wrote: On Thu, 18 Oct 2018, Robert Moskowitz wrote: On 10/18/18 4:14 PM, Johnny Hughes wrote: On 10/18/2018 12:36 PM, Walter H. wrote: On 18.10.2018 00:08, Johnny Hughes wrote: The bottom line .. we don't make the decision whether or not to use systemd or not. We rebuild RHEL source code. will there come a CentOS 6.11 which will be capable of TLS1.3 or HTTP/2? I'm sure there will come a CentOS 8, but when is it probable to be released? We have no idea .. we don't design what is in CentOS. If Red Hat adds those things to RHEL-6 then we will put them in CentOS .. If they don't we won't. And for example, if RH does not backport openSSL 1.1.1, you will not get EDDSA certificate support for TLS 1.3. Now you might not care about this for your servers and just continue to use ECDSA certs. Clients will increasingly encounter EDDSA certs and it will be interesting to see how this is handled in older clients. We have had years to spread support for ECDSA before it started appearing from servers. May not for EDDSA. I am under the impression that TLSv1.3 support appeared in 1.1.1 so I don't believe that you could do any TLS 1.3 with prior versions. https://wiki.openssl.org/index.php/TLS1.3 Yeah, I was kind of hedging my comment that maybe something for 1.3 would be in the earlier version, but yes, all the TLS 1.3 work was focused on openSSL 1.1.1. I was personally focused on EDDSA support. So a number of items have to appear in C6 for it to support TLS 1.3. More slowness in TLS 1.3 availability. Kind of flies in the face of a claim made against my HIP protocol which 'requires kernel level changes' and thus too hard to deploy. TLS is an upper layer protocol and changes easily roll out. Yeah, right. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] No searchable archives for this mailing list?
Hello all-- I can't seem to find a way to search the archives of this list right now though I DO remember doing that in the past. Any ideas? Thanks. -- Kay ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Can't access Samba shares from Nautilus
On 2018-10-19, Nicolas Kovacs
wrote:
> Le 19/10/2018 à 10:30, Nicolas Kovacs a écrit :
>> Any idea what's missing here or why this doesn't work as expected ?
>
> OK, I've investigated this a little further, and it looks like I have
> a partial success.
>
> In Nautilus, I pressed Ctrl+L and then typed in the Samba server URL:
>
> smb://amandine
>
> Now my two shares ("Public" and "Confidentiel") appeared OK in
> Nautilus. I could mount them and browse them perfectly.
>
> So it looks like there's something that prevents my server (amandine)
> from showing up in Nautilus when I click on "Browse network". Hmmm.
>
> Any suggestions ?
>
> Niki
>
Is avahi-daemon running on the client? That's what provides service
discovery.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] What are the differences between systemd and non-systemd Linux distros?
Japheth Cleaver wrote: > On 10/19/2018 5:09 AM, Jonathan Billings wrote: >> On Fri, Oct 19, 2018 at 01:07:46PM +0200, Simon Matter wrote: > The /sbin/service command is just a shell script. I'd suggest a patch to > send stderr/out to logger as well if I thought it would be accepted. (And > *manually executing* an init script with direct call was something > we were already supposed to be deprecating; the service command was the > standard environmental interface.) > > Frankly, I've had a lot more problems debugging mysterious systemd-based > startup failures than I ever had in a properly-written Red Hat init > script. (Again, vendor-agnostic init scripts can be hot messes, but > that's them...) Yeah. I have trouble finding the actual startup configs - /etc/systemd/system? /var/lib? whereeverthehell they are, do a locate as opposed to /etc/init.d to find the damn name (nfs? nfsd? idmapd? nfs-idmapd? rpc-idmapd?) mark ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] systemd automount of cifs share hangs
Running latest CentOS 7.5. Since I found out about automount unit files I've had mixed results using them to mount shares from my NAS. Lately they seem to hang if I touch the mount point, but I can start the mount unit without problems. I had it working months ago, so I'm thinking something changed in the systemd updates. For each mount point, I have two files in /etc/systemd/system named with the path of the mount point and with extensions .automount and .mount, following the systemd documentation. For example, srv-dav-name1.mount and srv-dav-name1.automount to mount a NAS share to /srv/dav/name1. I can issue "systemctl start srv-dav-name1.mount" and the mount completes instantly. But if I start the automount unit and ls the mount point, the shell hangs and eventually, a long time later (I haven't timed it, maybe an hour), I eventually get a prompt again. Control-C won't interrupt it. I can still ssh in and get another session so it's just the process that's accessing the mount point that hangs. Any suggestions on how I can debug this? I'm still new to finding the right log files. /var/log/messages doesn't show any errors like timeouts. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] What are the differences between systemd and non-systemd Linux distros?
On 10/19/2018 5:09 AM, Jonathan Billings wrote: On Fri, Oct 19, 2018 at 01:07:46PM +0200, Simon Matter wrote: That's really an important point, because those who started using Linux with Linux/systemd will be bound to Linux/systemd with their knowledge, switching to a *BSD or other Unix will be difficult. For me, I don't like to be limited in such ways. Having worked with the init systems in a bunch of different distros, I really *loved* having to write a different SysV init script for debian and RHEL, using different functions and different styles. Also, don't forget to actually package the Red Hat init scripts as /etc/rc.d/init.d/, because /etc/init.d is a symlink, while on debian it is the actual location, and if you weren't careful, your package would create an /etc/init.d directory and suddenly it's not even found by the init system. The first time I had to look at SysV init scripts on a Debian/Ubuntu box my eyes bled; if systemd had begun from that ecosystem I definitely would have understood its formation a bit more. But on Red Hat-derived distros, an initscript for a basic daemon is pretty simple and mostly boilerplate: copy/paste the sample file, maybe decide what you want to make tweakable in /etc/sysconfig/, then (if desired) build an RPM according to best practices. Virtually everything you might need that isn't provided by the 'functions' file is going to be your own custom logic for your own daemon, and it turns out that that usually doesn't change in a systemd landscape, resulting in a lot of workarounds, wrappers, and shell bits in unit files which would probably be more predictably understood in a single shell script to begin with. Building a single init script that works across ALL Linux distributions (and other unices) is indeed painful and ugly, so if a vendor wanted to make a declarative config file and wash their hands of, that's understandable. But the same goes for an xinetd.conf snippet, or any other service manager of the same ilk. And making a boilerplate /Red Hat-specific /init script is trivial. Heck, there was even an argument about which shell they're run with. And it was always fun when shell bugs cropped up in init scripts. A vendor writes an init script using bash features that aren't in another distro, but it still uses the #!/bin/sh shebang so you get really weird and difficult-to-diagnose startup errors. That's a larger *nix issue. As a proponent of dash on EL systems, I definitely think ensuring bashisms are called out and that /bin/sh means /bin/sh is probably a Good Thing. And heaven forbid you actually want to *SEE* any shell errors. Nothing is ever captured in any logs, you have to be physically looking at a console (be it a glass terminal or serial line) to capture the error. The /sbin/service command is just a shell script. I'd suggest a patch to send stderr/out to logger as well if I thought it would be accepted. (And *manually executing* an init script with direct call was something we were already supposed to be deprecating; the service command was the standard environmental interface.) Frankly, I've had a lot more problems debugging mysterious systemd-based startup failures than I ever had in a properly-written Red Hat init script. (Again, vendor-agnostic init scripts can be hot messes, but that's them...) -jc ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] What are the differences between systemd and non-systemd Linux distros?
On 10/18/2018 7:33 PM, Young, Gregory wrote: *** This response is my personal opinion and may not reflect that of my employer. *** *snip* If CentOS 8 were to switch back from systemd, I think you would be able to see the explosions from Alpha Centauri as all the developers out there lost their minds after spending all this time converting their apps to work with systemd. I think think some of the opposition to "switching back" misses the point. IMO there's nothing particularly wrong with systemd as a service manager, so folks wanting to use it as /just/ that (which accounts for the bulk of what SysV-style init scripts from vendors do) could still use it if they wanted. Initscripts work fine for traditional C unix daemons, but lots of other ecosystems (looking at java) are better served with other management systems. Disintangling from systemd's overall paradigm doesn't necessitate forcing everyone to write initscripts again for their own daemons. -jc ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Check version from installer disc
> > From the UI of the installer, Oh, this is great! Thank you. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] What are the differences between systemd and non-systemd Linux distros?
On Oct 17, 2018, at 6:55 PM, Warren Young wrote: > > I’d rather spend time advocating for and taking advantage of systemd’s > features than complaining about its weaknesses. > > (Automatic service restarts saved me a lot of work just a few weeks ago!) Today’s software project is going to take me all day, and it’s largely going to amount to reinventing systemd template units, since the software has to run on non-CentOS 7 boxes. I’d be done in an hour if I could just use template units. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] What are the differences between systemd and non-systemd Linux distros?
On Oct 19, 2018, at 5:07 AM, Simon Matter wrote: > > - the upgrade path from EL6 to EL7 is completely broken. Under what conditions would you actually use it? As we can see from the repeated attempts to get a reliable in-place upgrade process working, the community doesn’t seem to have much interest in the idea: https://lists.centos.org/pipermail/centos/2018-October/170379.html I believe this is because in-place upgrade is antithetical to the idea of a “stable” Linux distro in the first place. Once something’s configured and running, you just want it to keep doing so. In my world, OS upgrades are generally paired with new hardware or VMs. I did just this on an Ubuntu VM recently, which does have an in-place upgrade system. I’d been ignoring its motd offers of upgrade for years, on purpose, and only upgraded it from 14.04 LTS to 18.04 LTS when I needed to rebuild the VM anyway. That’s why I was on an LTS release in the first place: to give me the years of stability that let me batch the changes up into a single big-bang upgrade. CentOS is even better in this regard, with version lifetimes up around 10 years, rather than 5 for Ubuntu LTS. One of the reasons I chose to upgrade it recently was because Ubuntu 14.04 is about to fall out of support, so it was time to move. I believe a lot of the antipathy toward systemd is that people want “LTS” to be forever. That’s not going to happen until the rest of the world stops changing. That would be a very sad thing: it’s basically a wish for stagnation. If upgrading via separate hardware or a new VM is difficult, it calls into question the usefulness of your backup and restore strategy. Another advantage of this style of upgrade is that you have the prior box online and ready to fall back to if the manual upgrade fails. If an in-place upgrade fails, you’ve just lost the primary. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] What are the differences between systemd and non-systemd Linux distros?
On Fri, Oct 19, 2018 at 01:07:46PM +0200, Simon Matter wrote: > That's really an important point, because those who started using Linux > with Linux/systemd will be bound to Linux/systemd with their knowledge, > switching to a *BSD or other Unix will be difficult. For me, I don't like > to be limited in such ways. Having worked with the init systems in a bunch of different distros, I really *loved* having to write a different SysV init script for debian and RHEL, using different functions and different styles. Also, don't forget to actually package the Red Hat init scripts as /etc/rc.d/init.d/, because /etc/init.d is a symlink, while on debian it is the actual location, and if you weren't careful, your package would create an /etc/init.d directory and suddenly it's not even found by the init system. Oh, and as for 'grokkable' shell scripts used by init, they bear only a passing resemblance between distros, they even differed between releases of the same distro, making it so you had to learn a different weird init system for each distro. Heck, there was even an argument about which shell they're run with. And it was always fun when shell bugs cropped up in init scripts. A vendor writes an init script using bash features that aren't in another distro, but it still uses the #!/bin/sh shebang so you get really weird and difficult-to-diagnose startup errors. And heaven forbid you actually want to *SEE* any shell errors. Nothing is ever captured in any logs, you have to be physically looking at a console (be it a glass terminal or serial line) to capture the error. So, yes, people starting to use systemd won't know about having to do that. They're also not custom-crafting Modelines in their XF86Config file for a monitor that uses weird undocumented, non-VESA parameters, nor are they trying to track down the right interrupt to run their network card so it doesn't interfere with their sound card. I'm sure we could create a whole book of all the annoyances with older Linuxes that have been largely solved. I don't see systemd as the end-all, be-all init system, I just think it's heading in a good direction. Its important to provide feedback like people have on this list, although people in the CentOS community really ought to provide feedback to the upstream communities. Here's a good example for me: In other systemd-based distros, they've got the systemd --user enabled (RHEL/CentOS have it patched out). This breaks a lot of our use case because the systemd developers don't think that different sessions of the same user are distinct, so they want to use systemd --user to manage user processes. This breaks if you use session-based authentication services like Kerberos. systemd --user tries to start up processes outside of your PAM session, so it won't have access to your kerberos tickets. And of course, Gnome Terminal now uses a gnome-terminal-server process to be the parent of all terminal sessions, started by systemd (as your user, on behalf of PID1). So you log in, start up a terminal, and it doesn't have any Kerberos tickets. Now, what happens if you happen to use an NFS v4 volume for $HOME, which uses Kerberos 5 for authentication? Now not only does your terminal not have tickets, but IT CAN'T EVEN REACH $HOME. And of course, systemd --user wants to read and write files in $HOME, so the whole thing is broken. What do the systemd developers say? They want it so anyone who becomes your $USER should just automatically have access to your Kerberos ticket cache, so systemd can work. This is actually breaking from the way Kerberos has worked for decades. And it seems that the systemd developers have just decided that their way is better. But I'm going to keep pushing back. -- Jonathan Billings ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] What are the differences between systemd and non-systemd Linux distros?
> Valeri Galtsev wrote: >> On 10/17/18 7:55 PM, Warren Young wrote: > >>> Benno Rice is right: Lennart Poettering gets stuff done. > > Because he's funded. And I strongly suspect that a lot of that funding > comes from M$'s interest in Upstream. > >> >> With all due respect, many people just stopped offering any argument >> about systemd, and simply fled elsewhere which in _their_ opinion >> (and I am one of them) lies better in what they with their education >> and life experience is more reasonably resembling system suitable >> for servers. >> >> Servers are key word for me. You can see me using macintosh laptop in >> variety of places, that doens't mean MacOS will be my choice for server, >> so >> don't count laptopls into any statistics. The same is true about a bunch >> of other sysadmins I know, who mostly use Apple laptops, whereas run >> Linux, or UNIX-like, or [truly] UNIX servers. > > Actually, I've got CentOS on my 9 yr old Netbook, that I use while > traveling. Otherwise, my home workstation is CentOS 6, and I am NOT > looking forward to EOL. > > But Valeri's correct: people are tired of screaming and yelling about > systemd, because we've had years now of the response being "tough, it's > the Wave of the Future", and Poettering is like upper management: they > know, I mean, Everything, so why should they need to talk to end users (or > working sysadmins)? > > Lack of screaming and yelling filling this venue is more because "what's > the point?", and we have to get work done. Hi, A lot was already said but let me underline a few things from my personal point of view: - the upgrade path from EL6 to EL7 is completely broken. That's certainly a good thing for upstream, because they can sell even more support and training. I don't blame them for trying to make money, I just say from the technical point of view it's not the best solution. For home users it doesn't hurt too much but for the enterprise market it's bad. Migrating complex systems is a huge amount of work and takes a lot of time and manpower. In the end it means higher costs. - the migration to systemd is not really finished carefully in EL7. Just look into upstream's Bugzilla and see how many issues still exist and will probably not be fixed. I show you a simple example: we happen not mount some NFS filesystems on servers like this in /etc/fstab: ftp:/var/ftp/pub /mnt/nfs nfs bg,soft 0 0 Now, with every Linux since the last millennium one could simply bring down the system into maintenance mode with 'telinit 1', and all worked fine. Now try the same with EL7, do a 'systemctl rescue' or 'systemctl emergency' and see what happens. With lightning speed it does the wrong thing, brings down networked services, brings down the network, and doesn't unmount the NFS filesystems. Then try a 'df' or 'lsof' in rescue mode, it all hangs. Of course I found a solution, mount it with the option 'x-systemd.requires=network-online.target' and it behaves correctly. But really, it's broken, because it's always clear that NFS mounts always only work WITH network! That's just a single small example how things don't work as expected. - migrating from EL6 --> FreeBSD seems easier than migrating from EL6 --> EL7, IMHO. That's really an important point, because those who started using Linux with Linux/systemd will be bound to Linux/systemd with their knowledge, switching to a *BSD or other Unix will be difficult. For me, I don't like to be limited in such ways. In other words, systemd is a new operating system which still lacks a kernel :-) One thing I know for sure: if the *BSD folks were ever going to invent something like systemd, they will do it in a way which hurts less. Regards, Simon ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Check version from installer disc
On 10/18/2018 03:18 PM, Elliott Balsley wrote: >> From a end state perspective, it does not matter . . yum update after >> the install (of either) ends at exactly the same place. > > > I will not be running any updates, because I need to keep a specific old > version for software compatibility. I don't know which ISO the USB stick > was made from. > >> >> Also, a 'uname -a' from the command prompt will tell you .. > > > This would be perfect; how do you get to a shell from the installer? I only > see the option to install. > >> > That is also the only version which is tested at any point in time. >> (latest + all >> updates) > > > Tested by whom? Each software vendor may test and recommend differently. > I am talking about the CentOS Team .. The CentOS Project only tests CentOS-7 (or CentOS-6) as the latest version with all updates installed. We do not maintain any older versions .. so the only valid install is the latest tree with a yum update run. If you look on mirror.centos.org in any path other than the LATEST for each major version, you will see this: http://mirror.centos.org/centos/7.4.1708/ (that is from 7.4.1708 branch) It says this: This directory (and version of CentOS) is deprecated. For normal users, you should use /7/ and not /7.4.1708/ in your path. Please see this FAQ concerning the CentOS release scheme: https://wiki.centos.org/FAQ/General If you know what you are doing, and absolutely want to remain at the 7.4.1708 level, go to http://vault.centos.org/ for packages. Please keep in mind that 7.4.1708 no longer gets any updates, nor any security fix's. = signature.asc Description: OpenPGP digital signature ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Future Releases
On 10/18/2018 10:09 PM, Barry Brimer wrote: >>> No, there is no automated way to move from CentOS-6 to CentOS-7 .. and >>> we have no idea what will be in CentOS-8 until Red Hat releases RHEL-8. >>> We have no idea what will be in CentOS-6.11 until Red Hat releases >>> RHEL-6.11 .. and we have no idea what will be in the release of CentOS-7 >>> until Red Hat releases RHEL-7.6 .. literally, we take the source code >>> they release .. modify it for Trademarks and Logos .. and release it. >>> Until it is released, we don't have a clue. >> >> This is in the RHEL 7.6 Beta Release Notes: >> >> Part I. New Features >> This part documents new features and major enhancements introduced in >> Red Hat Enterprise Linux 7.6 Beta. >> >> Chapter 4. General Updates >> In-place upgrade from Red Hat Enterprise Linux 6 to Red Hat Enterprise >> Linux 7 >> >> An in-place upgrade offers a way of upgrading a system to a new major >> release of Red Hat Enterprise Linux by replacing the existing >> operating system. To perform an in-place upgrade, use the Preupgrade >> Assistant, a utility that checks the system for upgrade issues before >> running the actual upgrade, and that also provides additional scripts >> for the Red Hat Upgrade Tool. When you have solved all the problems >> reported by the Preupgrade Assistant, use the Red Hat Upgrade Tool to >> upgrade the system. > > I don't believe this is new to 7.6 Beta .. I believe this has been > available since the beginning of RHEL 7 > > https://access.redhat.com/solutions/1242133 > As I have posted about this many times before. That is a community controlled package set .. we need some people from the community to step up and modify / maintain those packages. I have asked again and again, on several fronts (blog, mailing lists, etc), to get volunteers to maintain those packages. I'll ask again now. Does someone from the community want to do the work to maintain those packages? Here are a couple previous attempts: https://blog.centos.org/2014/07/testing-centos-6-to-centos-7-upgrades-via-centos-testing-repo/ https://lists.centos.org/pipermail/centos/2016-May/159326.html We would be very happy to publish those RPMs if we can get them to be maintained by the community, and maintained in a consistent manner. Thanks, Johnny Hughes signature.asc Description: OpenPGP digital signature ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Can't access Samba shares from Nautilus
Le 19/10/2018 à 10:30, Nicolas Kovacs a écrit :
> Any idea what's missing here or why this doesn't work as expected ?
OK, I've investigated this a little further, and it looks like I have a
partial success.
In Nautilus, I pressed Ctrl+L and then typed in the Samba server URL:
smb://amandine
Now my two shares ("Public" and "Confidentiel") appeared OK in Nautilus.
I could mount them and browse them perfectly.
So it looks like there's something that prevents my server (amandine)
from showing up in Nautilus when I click on "Browse network". Hmmm.
Any suggestions ?
Niki
--
Microlinux - Solutions informatiques durables
7, place de l'église - 30730 Montpezat
Site : https://www.microlinux.fr
Blog : https://blog.microlinux.fr
Mail : i...@microlinux.fr
Tél. : 04 66 63 10 32
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
[CentOS] Can't access Samba shares from Nautilus
Hi,
I'm currently experimenting with Samba on a few sandbox machines.
On the server side, I have setup CentOS 7 with a basic Samba setup and
two shares, one public, the other password-protected.
I have two Windows 7 boxes in my network, and I can access the shares
perfectly, log in to the password-protected share, read and write files,
so this seems to work OK.
On my main Linux workstation (CentOS 7 + custom GNOME) I can't seem to
access these shares. When I click on the "Parcourir le réseau" ("Browse
network") icon in GNOME, Nautilus opens and shows a "Réseau Windows"
("Windows network") icon. Clicking on this icon, I only get the
following error message: "Impossible d'accéder à l'emplacement". Unable
to access this place.
So I fire up GNOME Terminal and see what this looks like on the command
line :
[kikinovak@alphamule:~] $ smbclient -L //amandine -N
Anonymous login successful
Sharename Type Comment
- ---
Public Disk Partage Public
ConfidentielDisk Partage Confidentiel
IPC$IPC IPC Service (Serveur de fichiers AMANDINE)
Reconnecting with SMB1 for workgroup listing.
Anonymous login successful
Server Comment
----
WorkgroupMaster
----
WORKGROUPAMANDINE
So far, so good. Now I try to connect as a user:
[kikinovak@alphamule:~] $ smbclient //amandine/Confidentiel -U kikinovak
Enter SAMBA\kikinovak's password:
Try "help" to get a list of possible commands.
smb: \> dir
. D0 Fri Oct 19 09:45:37 2018
.. D0 Fri Oct 19 08:47:34 2018
Lighthouse.jpg N 561276 Tue Jul 14 07:32:31 2009
Jellyfish.jpg N 775702 Tue Jul 14 07:32:31 2009
Desert.jpg N 845941 Tue Jul 14 07:32:31 2009
Koala.jpg N 780831 Tue Jul 14 07:32:31 2009
Hydrangeas.jpg N 595284 Tue Jul 14 07:32:31 2009
Tulips.jpg N 620888 Tue Jul 14 07:32:31 2009
Penguins.jpgN 777835 Tue Jul 14 07:32:31 2009
Chrysanthemum.jpg N 879394 Tue Jul 14 07:32:31 2009
149030696 blocks of size 1024. 139929224 blocks available
smb: \>
This also looks good. Now let's check what Samba-related packages are
installed on my workstation:
[kikinovak@alphamule:~] $ rpm -qa | grep samba
samba-client-libs-4.7.1-6.el7.x86_64
samba-client-4.7.1-6.el7.x86_64
samba-common-4.7.1-6.el7.noarch
samba-common-libs-4.7.1-6.el7.x86_64
[kikinovak@alphamule:~] $ rpm -qa | grep gvfs
gvfs-mtp-1.30.4-5.el7.x86_64
gvfs-smb-1.30.4-5.el7.x86_64
gvfs-afp-1.30.4-5.el7.x86_64
gvfs-client-1.30.4-5.el7.x86_64
gvfs-1.30.4-5.el7.x86_64
gvfs-archive-1.30.4-5.el7.x86_64
gvfs-goa-1.30.4-5.el7.x86_64
gvfs-fuse-1.30.4-5.el7.x86_64
gvfs-gphoto2-1.30.4-5.el7.x86_64
gvfs-afc-1.30.4-5.el7.x86_64
Any idea what's missing here or why this doesn't work as expected ?
Cheers from the sunny South of France,
Niki
--
Microlinux - Solutions informatiques durables
7, place de l'église - 30730 Montpezat
Site : https://www.microlinux.fr
Blog : https://blog.microlinux.fr
Mail : i...@microlinux.fr
Tél. : 04 66 63 10 32
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] What are the differences between systemd and non-systemd Linux distros?
On Friday 19 October 2018 00:41:12 Warren Young wrote: > > S…systemd is a Microsoft conspiracy against Linux? > I love this Now SystemD finally makes sense ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
