systemd on EL7
Hello, i finally caved in and started reading on systemd. It apperas it ( systemd) will be enabled by default on EL7. Does it mean i'll have to manually move all init scripts i wrote over the years ? I think the short answer is "no", but just want to clarify. // old unhappy guy ramblings Especially since i'm not too happy about these thousands of files to support systemd... // ramblings off. Thank you AZ
Re: Fed Up for 7?
On Sun, Feb 9, 2014 at 10:45 PM, ToddAndMargo wrote: > > I just upgraded a Fedora Core (FC) 19 workstation to > FC20 a week ago. It was an old Pentium 4 computer > I use at the customer's site. > > I used a utility from a Fedora project called Fed Up: > http://fedoraproject.org/wiki/FedUp > > It took about an hour. (You have to make sure FC19 is > all updates before it will work). > > SHOULD ALL UPDATES GO SO SMOOTHLY! Fed Up hit it > out of the ball park. > > Does anyone know if SL6 to SL7 will be as seamless? > Or, are we looking at a full wipe and reinstall? > > I have asked Fed Up if we can have a Fed Up for RHEL >https://bugzilla.redhat.com/show_bug.cgi?id=1060359 > So, far so, good. I have not heard a deafening *NO* > out of them yet. FedUp is being developed for RHEL 7: https://github.com/dashea/redhat-upgrade-tool It's also packaged in RHEL 7 as redhat-upgrade-tool. RH has announced that it'll support in-place upgrades: http://www.redhat.com/about/news/archive/2013/12/red-hat-announces-availability-of-red-hat-enterprise-linux-7-beta So you have to wait for redhat-upgrade-tool to be packaged for RHEL/SL 6...
RE: Future of Scientific Linux
Debian Science might need help from some of you, for instance: http://blends.debian.org/science/ Commits have slowed down considerably in 2014. Jean-Victor Côté, M.Sc.(Sciences économiques), (CPA, CMA), Post MBA J'ai aussi passé d'autres examens, dont les examens CFA. J'ai un profil Viadeo sommaire: http://www.viadeo.com/fr/profile/jean-victor.cote I also have a LinkedIn profile: http://www.linkedin.com/profile/view?id=2367003&trk=tab_pro Date: Sun, 9 Feb 2014 04:44:22 -0800 From: henrique...@yahoo.com Subject: Future of Scientific Linux To: scientific-linux-users@fnal.gov I'd like to know what people think about (possible) future scenarios for Scientific Linux. Let's say: - If SL becomes a CentOS SIG (builded using the CentOS Core) does it still worth the time or will you change to CentOS? - If nothing changes and SL continue to be build from SRPMs (with a huge delay compared to CentOS) - If SL dies to be replaced by CentOS at CERN and Fermi Lab Feel free to add new scenarios. --- Henrique C. S. Junior Química Industrial - UFRRJ Centro de Processamento de Dados - PMP Literatura - Química - Fotografia - Linux
Re: Exchange server alternative?
Our university is trying to get everyone moved to Office 365 and shutdown the few remaining departmental mail servers. The following is the response I wrote to one of our faculty member who was unhappy about having his mail stored on servers in the US. There are substantial savings to universities in moving to Gmail or Office 365, especially as these services host your student population for free. We're not just talking about an email solution -- the requirements are for a facility with an integrated calendar, address book, mobile access and collaboration features as well as email. The only alternative to Office 365 and Google Apps for Education that I am aware of is Zimbra. There is an open source version of Zimbra, but most organizations would want to purchase a commercial version which has more features. There are also third parties that provide a Zimbra hosted solution. Who is using Zimbra? Simon Fraser, Georgia Tech, Earlham College and Carleton College are using it for everyone. Texas A&M give faculty the option of using Zimbra or Exchange. The University of Pennsylvania uses Zimbra for some of their users but they also have Exchange and Microsoft Live. Purdue University use Zimbra but some departments are on Exchange. Are more universities moving to Zimbra? Not as far as I can see. I have references to Bucknell, St. Olaf and Wheaton College having moved off of Zimbra to either Office 365 or Google Apps. Bucknell seemed especially unhappy about their Zimbra experience as one of their IT people described it as a disaster! Texax A&M which are currently listed on the Zimbra web site as a customer are dropping it. Their IT Advisory Committee decided last October that all email on campus should be moved to either Office 365 or Google Apps. Their timeline is to have students moved to the new service by August, 2014. The topic of mail systems comes up on three different mailing lists I subscribe to and there is regular discussion of moving to Office 365 or Google Apps but no one talks of moving to Zimbra (or anything else for that matter).
Re: Exchange server alternative?
On Sun, Feb 9, 2014 at 3:50 PM, Paul Robert Marino wrote: > On Sun, Feb 9, 2014 at 10:46 AM, Nico Kadel-Garcia wrote: >> It also ties directly to backup. Backup is often ignored, or relegated >> to an afterthought for critical email systems. > > I severely doubt you have never sat across a table from a S.E.C. > auditor, they usually are very much interested in your backups. As a SEC auditor, no. The IT department preparing the checklists for SOX compliance, yes. Being asked to "edit" the data before it was given to auditors? Lord, yes, and that helped cause professional problems for me. I refused to lie, and the data was late because I *deleted* the old accounts, then made a report, I didn't edit old user accounts out of the report. > matter of fact they tend to trust tape backups more than the live data > in the systems because thats usually how they catch people altering > data after the fact. It's easy to edit the data in your running And I agree with them. Off-site disk mirroring for disaster recovery and backup access, and tape backups for Iron Mountain or other off-site archival It's too easy to delete data accidentally, as well on live mirrors. That's not just a "it can be manipulated" issue, that's a "it can be accidentally deleted or currupted" issue. It's partly why I like replacing local Linux messaging nservices with GMail services: they've already done most of the tricky parts. > servers, but its far more difficult to edit data on a tape with a well > documented chain of custody in a timely manner and as a result its > what usually gets overlooked if any one tries to cover any thing up. > Also SEC auditors will make a public example of you, if your backup > are not in order because that makes them suspect you are assisting > someone with covering something up. But what shows up in the SOX checklist is just that. Boxes on a checklist. It's often quite fraudulent: just because you have a policy that says passwords shall not be shared does not mean that a system architect is not insisting on setting and sending new passwords in plaintext via email "to make sure they work", despite the explicit written policy.
Re: Exchange server alternative?
On Sun, Feb 9, 2014 at 10:46 AM, Nico Kadel-Garcia wrote: > On Sun, Feb 9, 2014 at 8:58 AM, Paul Robert Marino > wrote: >> You know what you also can't do with Gmail create a SOX compliant export for >> regulators if you get audited. > > You mean like the regulations the Google Apps Vault was designed to > support? Google Vault is not SOX compliant because users can decide to make a conversation off the record. its in their FAQ. I can see the risks if you've convinced that "legal" tapping > may be committed, to your detriment. It's a risk of any SAAS > businesses, and for a company with military or high value > international traffic, certainly. Consider the NSA or even foreign > intelligence to already have access to all the traffic. But in many > environments, *they have it anyway*, without a warrant. The > "Carnivore" email monitoring system is still in place, or a renamed > version of it, to monitor email at the backbones of the Internet. Yes I'm aware of that for any one who isn't familiar with Carnivore well the FBI has their own version of the NSA's Phone collection bigdata softwaer for email on internet backbones and its a lot older http://www.linuxjournal.com/article/5062 > In-house email repositories are vulnerable to external abuse of > backdoors in firewalls and routers to grab your internal credentials > and go poking around your systems, or rootkitted laptops may have > already penetrated your systems. > > Securing against that kind of intrusion is a *lot* of work, and it > doesn't usually pay the bills or get glowing project reports on your > annual reviews. Using something like Scientific Linux and RHEL for > internal services is a good place to start. Handing it off to someone > who can afford a very sophisticated group to do precisely that kind of > protecton or, as needed, access i often a wise investment. It can be and it also depends on what industry you are in you may need it any way even if you outsource your email system. > >> So if there is reason to believe that your companies emails contains data >> pertinent to the financial transactions of your company and your company >> gets audited you are in deep trouble. It is also the legal responsibility of >> the person or people in charge of maintaining the email system to ensure the >> compliant backups are taken and made available upon request. >> That's why most large and or financial companies in the united states won't >> use it. > > They're learning. Setting up in-house mail systems is fraught with > adventures: ensuring high availability, supportability, archival > access, and infosec have all grown and evolved. This is where "build > your own" with even a good environment like Scientific Linux gets > adventuresome. Setting up reliable backups, firewall control to the > servers, good failover, spam Small companies you are somewhat right but not completely many of them hire a consulting company or managed network security company to do it for them on their own hardware, larger companies still tend to hire in house staff but I've seen some which used managed infosec firms as well. I actually work for a managed financial network security firm some years back it was a lucrative business all around, it saved our clients a fortune in staff and they paid us a lot better than most in house department for one company would get, although it was a whole lot of work. and going through all of those weekly Nessus scan reports and keeping all those custom snort rules up to date was a chore. and dnot even get me started on the fun of trying to get several different companies with limited in house staff to install critical patches in a timely manner. > >> And some times the regulators are the ones who are actually asking for the >> tap via a compliance officer on some ones emails without managerial approval >> and its really bad if they can't do that. >> You can thank Enron for that. > > That gets tricky, and it's not just Enron. Archival of mail beyond the > required period is considered, by some, to be a legal liability: > whether or not they've been engaged in wrongdoing, it preserves > evidence that might be used against them in court. Heck, you should Well thats why you should always delete backups containing obsolete data like old emails as soon as you are no longer legally required to keep them. > have seen the *outgoing* email filter I was involved in setting up > once, to filter all email against a secured database of "sensitive" > content that should not be in email. Creating filters based on data > you are not allowed to see is an artform. No doubt. > > It also ties directly to backup. Backup is often ignored, or relegated > to an afterthought for critical email systems. I severely doubt you have never sat across a table from a S.E.C. auditor, they usually are very much interested in your backups. As a matter of fact they tend to trust tape backups more than the live data in the systems because thats usually how
Re: Future of Scientific Linux
On Sun, Feb 9, 2014 at 7:44 AM, Henrique C. S. Junior wrote: > I'd like to know what people think about (possible) future scenarios for > Scientific Linux. Let's say: > - If SL becomes a CentOS SIG (builded using the CentOS Core) does it still > worth the time or will you change to CentOS? Stick with SL. CentOS, historically, has mapped one-to-one with the contents of RHEL. SL has been willing to add very, very useful components to the basic build, particularly hooks kto access third-party repositories such as EPEL and RPMfusion. Those are invaluable to work I do every day, and save me work burining new virtual machines or doing base installs. > - If nothing changes and SL continue to be build from SRPMs (with a huge > delay compared to CentOS) See above. The delay is not "huge", and I'm often forced to schedule package updates for maintenance windows, anyway. A churning set of updates is begging for environment instability in production environments. I've often locked down "snapshots" of yum repositories, and so that all production hosts work from the same locked down repo, and left ongoing updates active in a separate repo. The RPM contents are hardlinked among them to save disk space on the yum server or network file share: it's pretty effective. > - If SL dies to be replaced by CentOS at CERN and Fermi Lab > > Feel free to add new scenarios. CERN manages to create a black hole and the Earth is eaten, and any astronauts in orbit fly off and colonize Europa?
Re: Exchange server alternative?
On Sun, Feb 9, 2014 at 8:58 AM, Paul Robert Marino wrote: > You know what you also can't do with Gmail create a SOX compliant export for > regulators if you get audited. You mean like the regulations the Google Apps Vault was designed to support? I can see the risks if you've convinced that "legal" tapping may be committed, to your detriment. It's a risk of any SAAS businesses, and for a company with military or high value international traffic, certainly. Consider the NSA or even foreign intelligence to already have access to all the traffic. But in many environments, *they have it anyway*, without a warrant. The "Carnivore" email monitoring system is still in place, or a renamed version of it, to monitor email at the backbones of the Internet. In-house email repositories are vulnerable to external abuse of backdoors in firewalls and routers to grab your internal credentials and go poking around your systems, or rootkitted laptops may have already penetrated your systems. Securing against that kind of intrusion is a *lot* of work, and it doesn't usually pay the bills or get glowing project reports on your annual reviews. Using something like Scientific Linux and RHEL for internal services is a good place to start. Handing it off to someone who can afford a very sophisticated group to do precisely that kind of protecton or, as needed, access i often a wise investment. > So if there is reason to believe that your companies emails contains data > pertinent to the financial transactions of your company and your company > gets audited you are in deep trouble. It is also the legal responsibility of > the person or people in charge of maintaining the email system to ensure the > compliant backups are taken and made available upon request. > That's why most large and or financial companies in the united states won't > use it. They're learning. Setting up in-house mail systems is fraught with adventures: ensuring high availability, supportability, archival access, and infosec have all grown and evolved. This is where "build your own" with even a good environment like Scientific Linux gets adventuresome. Setting up reliable backups, firewall control to the servers, good failover, spam > And some times the regulators are the ones who are actually asking for the > tap via a compliance officer on some ones emails without managerial approval > and its really bad if they can't do that. > You can thank Enron for that. That gets tricky, and it's not just Enron. Archival of mail beyond the required period is considered, by some, to be a legal liability: whether or not they've been engaged in wrongdoing, it preserves evidence that might be used against them in court. Heck, you should have seen the *outgoing* email filter I was involved in setting up once, to filter all email against a secured database of "sensitive" content that should not be in email. Creating filters based on data you are not allowed to see is an artform. It also ties directly to backup. Backup is often ignored, or relegated to an afterthought for critical email systems.
Re: Exchange server alternative?
You know what you also can't do with Gmail create a SOX compliant export for regulators if you get audited.So if there is reason to believe that your companies emails contains data pertinent to the financial transactions of your company and your company gets audited you are in deep trouble. It is also the legal responsibility of the person or people in charge of maintaining the email system to ensure the compliant backups are taken and made available upon request.That's why most large and or financial companies in the united states won't use it.And some times the regulators are the ones who are actually asking for the tap via a compliance officer on some ones emails without managerial approval and its really bad if they can't do that.You can thank Enron for that.-- Sent from my HP Pre3On Feb 9, 2014 1:25, Nico Kadel-Garcia wrote: On Sat, Feb 8, 2014 at 6:53 PM, Paul Robert Marino wrote: > info sec is not the problem it's a record keeping issue. Info sec for email is *always* a problem. It's also critical to the record keeping: the ability to re-route, or delete, or backfill email needs to be handled. (Do not get me *started* on desires to backfill email that never happened, or to silently tap people's email with or without managerial permission! Switching to GMail made it possible for me to say "can't be done!!!" and avoid responsibility for such abuses.) Fortunately, modern IMAP based email systems give easy ways to transfer or replicate email wholesale ti alternative servers, wholesale. Thank you, *gods* for the migration from POP based services, which have mostly disappeared but stored all the folder information on the client. For most clients, they can pretty much cut and paste their old Exchange folders to a new IMAP environment. *Migrating* from Exchange to the new environment takes time and effort. For folks recommending Zimbra or Zarafa, I'd be very curious how they migrate data from Exchange clients. I'm sure that part's not just "drop-in replacement".
Re: Future of Scientific Linux
On 09/02/14 13:44, Henrique C. S. Junior wrote: > I'd like to know what people think about (possible) future scenarios for > Scientific Linux. Let's say: > - If SL becomes a CentOS SIG (builded using the CentOS Core) does it > still worth the time or will you change to CentOS? > - If nothing changes and SL continue to be build from SRPMs (with a > huge delay compared to CentOS) > - If SL dies to be replaced by CentOS at CERN and Fermi Lab > > Feel free to add new scenarios. I will suggest this in stead: Have patience! The SL team is figuring out what's they will do, and I guess they're in contact with CentOS about this too. Let's avoid speculating, it's way too early for that. -- kind regards, David Sommerseth
Re: Exchange server alternative?
On 09/02/14 07:25, Nico Kadel-Garcia wrote: > For folks recommending Zimbra or Zarafa, I'd be very curious how they > migrate data from Exchange clients. I'm sure that part's not just > "drop-in replacement". There are a few ways. One is to use a utility provided in the Zimbra (not sure if it's only in Network Edition or also in OSE), which will migrate selected or all user accounts from Exchange to Zimbra. This is a Windows binary. Another approach for NE users is to do it per client, using "drag'n'drop" using the Zimbra Outlook Connector. Or in worst case using IMAP (which works for NE and OSE). Also via the Admin webUI, you can use the migration wizard. I don't remember now if it has embedded Exchange support. But there's support for migrating data from IMAP and other Zimbra servers at least. You can even provide a list of users via a file, containing username and passwords for fully automated migration. -- kind regards, David Sommerseth
Re: Future of Scientific Linux
On Sun, Feb 9, 2014 at 7:44 AM, Henrique C. S. Junior wrote: > > I'd like to know what people think about (possible) future scenarios for > Scientific Linux. Let's say: > - If SL becomes a CentOS SIG (builded using the CentOS Core) does it still > worth the time or will you change to CentOS? > - If nothing changes and SL continue to be build from SRPMs (with a huge > delay compared to CentOS) > - If SL dies to be replaced by CentOS at CERN and Fermi Lab What's the point of speculating? Or even pseudo-planning? Have you read [1]? [1] http://listserv.fnal.gov/scripts/wa.exe?A2=ind1401&L=scientific-linux-users&T=0&P=21431
Future of Scientific Linux
I'd like to know what people think about (possible) future scenarios for Scientific Linux. Let's say: - If SL becomes a CentOS SIG (builded using the CentOS Core) does it still worth the time or will you change to CentOS? - If nothing changes and SL continue to be build from SRPMs (with a huge delay compared to CentOS) - If SL dies to be replaced by CentOS at CERN and Fermi Lab Feel free to add new scenarios. --- Henrique C. S. Junior Química Industrial - UFRRJ Centro de Processamento de Dados - PMP Literatura - Química - Fotografia - Linux
