Who is the behind Webtatic repository and do you trust it Announcing the arrival of Valued Associate #679: Cesar Manara Planned maintenance scheduled April 23, 2019 at 23:30 UTC (7:30pm US/Eastern) Come Celebrate our 10 Year Anniversary!About dedicated code repository server and othersGit: can I store known repository in the repository?repository and its content?What is the difference between the base and updates repo in CentOS?Disable a repository and remove all the software installed from itIs ius's epel the same repository as fedoralprojects?Securing local repository with SSH and chroothow to choose the correct repository for new software on CentosRedhat repository server packages auto check and updateHow do I mount the CentOS 7 ISO and add it as a yum repository
Why doesn't the university give past final exams' answers?
Is my guitar’s action too high?
How can I introduce the names of fantasy creatures to the reader?
Trying to enter the Fox's den
Providing direct feedback to a product salesperson
How to leave only the following strings?
Suing a Police Officer Instead of the Police Department
Why does BitLocker not use RSA?
Why is one lightbulb in a string illuminated?
What is the difference between 准时 and 按时?
Does traveling In The United States require a passport or can I use my green card if not a US citizen?
Can a Knight grant Knighthood to another?
Can I take recommendation from someone I met at a conference?
Can a Wizard take the Magic Initiate feat and select spells from the Wizard list?
Compiling and throwing simple dynamic exceptions at runtime for JVM
Where is Bhagavad Gita referred to as Hari Gita?
How to create a command for the "strange m" symbol in latex?
How to mute a string and play another at the same time
Weaponising the Grasp-at-a-Distance spell
"Destructive force" carried by a B-52?
Recursive calls to a function - why is the address of the parameter passed to it lowering with each call?
Can gravitational waves pass through a black hole?
tabularx column has extra padding at right?
Like totally amazing interchangeable sister outfit accessory swapping or whatever
Who is the behind Webtatic repository and do you trust it
Announcing the arrival of Valued Associate #679: Cesar Manara
Planned maintenance scheduled April 23, 2019 at 23:30 UTC (7:30pm US/Eastern)
Come Celebrate our 10 Year Anniversary!About dedicated code repository server and othersGit: can I store known repository in the repository?repository and its content?What is the difference between the base and updates repo in CentOS?Disable a repository and remove all the software installed from itIs ius's epel the same repository as fedoralprojects?Securing local repository with SSH and chroothow to choose the correct repository for new software on CentosRedhat repository server packages auto check and updateHow do I mount the CentOS 7 ISO and add it as a yum repository
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;
Webtatic repository has lots of useful packages for CentOS and RedHat. However the repository is very opaque and I have hard time to find information of who is behind it, appart of "Andrew Thompson", known as Andy around here.
He seems to be doing a great job providing all these useful packages. I need to use the repository on live company servers and using unofficial repositories triggers immediately an alarm in me.
- Is it a single person repository?
- Is it backed by a company?
- It seems to exist for for few years now, but what about tomorrow? (apart of the giant asteroid that can wipe us all)
- How secure is it? I don't want next
yum update
to download a trojan. - How quickly are the security fixes deployed of provided packages? ....
Feedback from real life CentOS/RedHat administrators will be greatly appreciated.
Thanks in advance
centos redhat repository
add a comment |
Webtatic repository has lots of useful packages for CentOS and RedHat. However the repository is very opaque and I have hard time to find information of who is behind it, appart of "Andrew Thompson", known as Andy around here.
He seems to be doing a great job providing all these useful packages. I need to use the repository on live company servers and using unofficial repositories triggers immediately an alarm in me.
- Is it a single person repository?
- Is it backed by a company?
- It seems to exist for for few years now, but what about tomorrow? (apart of the giant asteroid that can wipe us all)
- How secure is it? I don't want next
yum update
to download a trojan. - How quickly are the security fixes deployed of provided packages? ....
Feedback from real life CentOS/RedHat administrators will be greatly appreciated.
Thanks in advance
centos redhat repository
1
I would note that there are at least two very different levels of trust: as a developer, I care mainly if the packages are clean (not altered maliciously) and reasonably up-to-date. It is as a sysadmin that I care enormously about long term support, and longevity of the maintainers.
– jhominal
Apr 5 '17 at 17:35
Correct. Here I ask as sysadmin, changing server OS/teach only every 5 or more years
– Niki
Apr 5 '17 at 21:51
Both as a system admin and developer it's important to use decent sources of builds. Otherwise you'll risk having problems such as bad builds causing bugs or limitations in feature sets, etc. A bad source might be distributing packages without things like -O2 and you'll be totalyl clueless as to it.
– jgmjgm
Apr 16 at 15:57
add a comment |
Webtatic repository has lots of useful packages for CentOS and RedHat. However the repository is very opaque and I have hard time to find information of who is behind it, appart of "Andrew Thompson", known as Andy around here.
He seems to be doing a great job providing all these useful packages. I need to use the repository on live company servers and using unofficial repositories triggers immediately an alarm in me.
- Is it a single person repository?
- Is it backed by a company?
- It seems to exist for for few years now, but what about tomorrow? (apart of the giant asteroid that can wipe us all)
- How secure is it? I don't want next
yum update
to download a trojan. - How quickly are the security fixes deployed of provided packages? ....
Feedback from real life CentOS/RedHat administrators will be greatly appreciated.
Thanks in advance
centos redhat repository
Webtatic repository has lots of useful packages for CentOS and RedHat. However the repository is very opaque and I have hard time to find information of who is behind it, appart of "Andrew Thompson", known as Andy around here.
He seems to be doing a great job providing all these useful packages. I need to use the repository on live company servers and using unofficial repositories triggers immediately an alarm in me.
- Is it a single person repository?
- Is it backed by a company?
- It seems to exist for for few years now, but what about tomorrow? (apart of the giant asteroid that can wipe us all)
- How secure is it? I don't want next
yum update
to download a trojan. - How quickly are the security fixes deployed of provided packages? ....
Feedback from real life CentOS/RedHat administrators will be greatly appreciated.
Thanks in advance
centos redhat repository
centos redhat repository
edited Apr 4 '16 at 2:09
chicks
3,06072033
3,06072033
asked Apr 1 '16 at 7:46
NikiNiki
5614
5614
1
I would note that there are at least two very different levels of trust: as a developer, I care mainly if the packages are clean (not altered maliciously) and reasonably up-to-date. It is as a sysadmin that I care enormously about long term support, and longevity of the maintainers.
– jhominal
Apr 5 '17 at 17:35
Correct. Here I ask as sysadmin, changing server OS/teach only every 5 or more years
– Niki
Apr 5 '17 at 21:51
Both as a system admin and developer it's important to use decent sources of builds. Otherwise you'll risk having problems such as bad builds causing bugs or limitations in feature sets, etc. A bad source might be distributing packages without things like -O2 and you'll be totalyl clueless as to it.
– jgmjgm
Apr 16 at 15:57
add a comment |
1
I would note that there are at least two very different levels of trust: as a developer, I care mainly if the packages are clean (not altered maliciously) and reasonably up-to-date. It is as a sysadmin that I care enormously about long term support, and longevity of the maintainers.
– jhominal
Apr 5 '17 at 17:35
Correct. Here I ask as sysadmin, changing server OS/teach only every 5 or more years
– Niki
Apr 5 '17 at 21:51
Both as a system admin and developer it's important to use decent sources of builds. Otherwise you'll risk having problems such as bad builds causing bugs or limitations in feature sets, etc. A bad source might be distributing packages without things like -O2 and you'll be totalyl clueless as to it.
– jgmjgm
Apr 16 at 15:57
1
1
I would note that there are at least two very different levels of trust: as a developer, I care mainly if the packages are clean (not altered maliciously) and reasonably up-to-date. It is as a sysadmin that I care enormously about long term support, and longevity of the maintainers.
– jhominal
Apr 5 '17 at 17:35
I would note that there are at least two very different levels of trust: as a developer, I care mainly if the packages are clean (not altered maliciously) and reasonably up-to-date. It is as a sysadmin that I care enormously about long term support, and longevity of the maintainers.
– jhominal
Apr 5 '17 at 17:35
Correct. Here I ask as sysadmin, changing server OS/teach only every 5 or more years
– Niki
Apr 5 '17 at 21:51
Correct. Here I ask as sysadmin, changing server OS/teach only every 5 or more years
– Niki
Apr 5 '17 at 21:51
Both as a system admin and developer it's important to use decent sources of builds. Otherwise you'll risk having problems such as bad builds causing bugs or limitations in feature sets, etc. A bad source might be distributing packages without things like -O2 and you'll be totalyl clueless as to it.
– jgmjgm
Apr 16 at 15:57
Both as a system admin and developer it's important to use decent sources of builds. Otherwise you'll risk having problems such as bad builds causing bugs or limitations in feature sets, etc. A bad source might be distributing packages without things like -O2 and you'll be totalyl clueless as to it.
– jgmjgm
Apr 16 at 15:57
add a comment |
4 Answers
4
active
oldest
votes
The question is not if we trust Andy, it is if you trust Andy.
I'm not familiar with the repository but the donation button suggests a personal effort. Feel free to contribute if it has value to you.
Packages look to be GnuPG signed, so it is possible to verify with some certainty the packages are authentic. You can also check if he is on the web of trust.
Regarding quality or security, its best if someone else has a look at how the repository is doing. This could be you. Subscribe to the upstream security advisories and check if they are affected. Evaluate the packages as a reviewer would for Fedora.
If continuity of these packages is important to you, acquire similar skills. Learn packaging or hire someone who can.
add a comment |
Back when I first started as a Linux admin 8 years ago I used to use a popular third party repository to upgrade my LAMP stack. It was run by a single individual. One of the primary reasons was developers pressuring me for a newer version of PHP than what came with RHEL 5. It ended up biting me.
The person abandoned the repositories so I was no longer getting security updates, but I also could not remove all the newer packages and go back to the RHEL packages due to the RHEL version of PHP being from too old a branch. Moving to that repository's LAMP stack touched at-least half a dozen packages or more. So, maintaining those packages and recompiling them all by hand from time to time would be a major PITA.
You also lose the ability to use the OS vendor's security advisories regarding CVE vulnerabilities to determine whether your system is or is not vulnerable to a certain exploit for those packages. This proved to be a major problem for me years later, even though I would have never anticipated at the time.
So, in addition to having trust in the maintainers integrity and technical skills, you have to ask yourself whether you trust them not to move on to a new job that wont allow them to maintain the repository, or get married and have kids and no longer have time, etc....
Since then I have been very skittish about using any third party repositories, especially those that only have one person running them.
Thanks! These are all the questions I am already asking my self, however your experience is partially an answer to my main question. Now I just hope can get some more specific feedback about Webtatic repo in particular, otherwise I think will follow your advise, which is also my gut feeling and what I always did until now. (Like you, its about PHP version...)
– Niki
Apr 4 '16 at 19:03
add a comment |
Remi is the standard for latest builds of PHP for RHEL. He is a long established and reliable source for RPM packages that's being actively maintained and includes as many relevant packages as possible.
The webtatic source is unknown and untrusted. It shouldn't be used at all.
I found it running on a legacy system. It had a serious memory leak in it. I replaced it with Remi, exactly the same PHP version and suddenly everything's running smoothly. I don't think it's even a stable compile.
add a comment |
In general, unless you know there's a feature you actually seriously need and actually can't live without (as many people will believe they can't .. until it's a choice between 'old' or nothing) then stick with the vendor packages.
Teach your webdevs why a branch isn't a stagnant snapshot, and show them - PHP is a great one for this - how upstream rebasing brings in far more bugs; and how in many cases the response time for a backport around a security issue is actually faster and more reliably delivered by a distro in their maintained branch (because it's someone's priority and job) than in the upstream OEM version.
You may be the one who actually succeeds, and you owe it to the rest of us to try ;-)
PHP is a pretty poor example for this: We almost always need point releases for bugfixes, but the distros do not provide them. They have good reason, of course. But having the repos available where we can get bugfixes in point releases is extremely helpful.
– Michael Hampton♦
Aug 3 '18 at 15:02
We use different distros, I suspect. I haven't seen a lack of bugfix and security updates in PHP, even though the distro has branched at a certain upstream version and the version appears locked to the layman. rpm -q php --changelog shows weekly updates with bugfixes and security updates aplenty. I'm sorry if you're not getting the same mileage :-(
– user2066657
Aug 3 '18 at 15:41
Definitely different distros. I don't see that in PHP on RHEL 7.5 or CentOS 7.5. Fedora has updated PHP packages though, and generally doesn't have this problem. Fortunately Remi Collet, the Red Hat employee who builds RHEL's PHP packages, also maintains repos with PHP point releases. Which is part of the reason Red Hat hired him.
– Michael Hampton♦
Aug 3 '18 at 15:49
Hmm. I was looking at the RH/Centos ones. I can't explain why you're not seeing the same --changelog I am, and I'm sorry to see it. I wish Remi would update SCL a bit more. I'm seeing slowdowns there (7.1.8 and not even a package release to update). I was actually mostly convinced he'd moved on, this morning. If only Fedora wasn't a mayfly.
– user2066657
Aug 3 '18 at 20:53
Really? I don't know what packages you are looking at but I see no updates since php-5.4.16-45.el7. Maybe you're looking at something from a software collection? Speaking of which, SCLs are on a bit slower pace. If you actually want PHP releases as they happen, hit up rpms.remirepo.net
– Michael Hampton♦
Aug 3 '18 at 20:56
|
show 2 more comments
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "2"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f767504%2fwho-is-the-behind-webtatic-repository-and-do-you-trust-it%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
The question is not if we trust Andy, it is if you trust Andy.
I'm not familiar with the repository but the donation button suggests a personal effort. Feel free to contribute if it has value to you.
Packages look to be GnuPG signed, so it is possible to verify with some certainty the packages are authentic. You can also check if he is on the web of trust.
Regarding quality or security, its best if someone else has a look at how the repository is doing. This could be you. Subscribe to the upstream security advisories and check if they are affected. Evaluate the packages as a reviewer would for Fedora.
If continuity of these packages is important to you, acquire similar skills. Learn packaging or hire someone who can.
add a comment |
The question is not if we trust Andy, it is if you trust Andy.
I'm not familiar with the repository but the donation button suggests a personal effort. Feel free to contribute if it has value to you.
Packages look to be GnuPG signed, so it is possible to verify with some certainty the packages are authentic. You can also check if he is on the web of trust.
Regarding quality or security, its best if someone else has a look at how the repository is doing. This could be you. Subscribe to the upstream security advisories and check if they are affected. Evaluate the packages as a reviewer would for Fedora.
If continuity of these packages is important to you, acquire similar skills. Learn packaging or hire someone who can.
add a comment |
The question is not if we trust Andy, it is if you trust Andy.
I'm not familiar with the repository but the donation button suggests a personal effort. Feel free to contribute if it has value to you.
Packages look to be GnuPG signed, so it is possible to verify with some certainty the packages are authentic. You can also check if he is on the web of trust.
Regarding quality or security, its best if someone else has a look at how the repository is doing. This could be you. Subscribe to the upstream security advisories and check if they are affected. Evaluate the packages as a reviewer would for Fedora.
If continuity of these packages is important to you, acquire similar skills. Learn packaging or hire someone who can.
The question is not if we trust Andy, it is if you trust Andy.
I'm not familiar with the repository but the donation button suggests a personal effort. Feel free to contribute if it has value to you.
Packages look to be GnuPG signed, so it is possible to verify with some certainty the packages are authentic. You can also check if he is on the web of trust.
Regarding quality or security, its best if someone else has a look at how the repository is doing. This could be you. Subscribe to the upstream security advisories and check if they are affected. Evaluate the packages as a reviewer would for Fedora.
If continuity of these packages is important to you, acquire similar skills. Learn packaging or hire someone who can.
answered Apr 4 '16 at 0:44
John MahowaldJohn Mahowald
9,0711713
9,0711713
add a comment |
add a comment |
Back when I first started as a Linux admin 8 years ago I used to use a popular third party repository to upgrade my LAMP stack. It was run by a single individual. One of the primary reasons was developers pressuring me for a newer version of PHP than what came with RHEL 5. It ended up biting me.
The person abandoned the repositories so I was no longer getting security updates, but I also could not remove all the newer packages and go back to the RHEL packages due to the RHEL version of PHP being from too old a branch. Moving to that repository's LAMP stack touched at-least half a dozen packages or more. So, maintaining those packages and recompiling them all by hand from time to time would be a major PITA.
You also lose the ability to use the OS vendor's security advisories regarding CVE vulnerabilities to determine whether your system is or is not vulnerable to a certain exploit for those packages. This proved to be a major problem for me years later, even though I would have never anticipated at the time.
So, in addition to having trust in the maintainers integrity and technical skills, you have to ask yourself whether you trust them not to move on to a new job that wont allow them to maintain the repository, or get married and have kids and no longer have time, etc....
Since then I have been very skittish about using any third party repositories, especially those that only have one person running them.
Thanks! These are all the questions I am already asking my self, however your experience is partially an answer to my main question. Now I just hope can get some more specific feedback about Webtatic repo in particular, otherwise I think will follow your advise, which is also my gut feeling and what I always did until now. (Like you, its about PHP version...)
– Niki
Apr 4 '16 at 19:03
add a comment |
Back when I first started as a Linux admin 8 years ago I used to use a popular third party repository to upgrade my LAMP stack. It was run by a single individual. One of the primary reasons was developers pressuring me for a newer version of PHP than what came with RHEL 5. It ended up biting me.
The person abandoned the repositories so I was no longer getting security updates, but I also could not remove all the newer packages and go back to the RHEL packages due to the RHEL version of PHP being from too old a branch. Moving to that repository's LAMP stack touched at-least half a dozen packages or more. So, maintaining those packages and recompiling them all by hand from time to time would be a major PITA.
You also lose the ability to use the OS vendor's security advisories regarding CVE vulnerabilities to determine whether your system is or is not vulnerable to a certain exploit for those packages. This proved to be a major problem for me years later, even though I would have never anticipated at the time.
So, in addition to having trust in the maintainers integrity and technical skills, you have to ask yourself whether you trust them not to move on to a new job that wont allow them to maintain the repository, or get married and have kids and no longer have time, etc....
Since then I have been very skittish about using any third party repositories, especially those that only have one person running them.
Thanks! These are all the questions I am already asking my self, however your experience is partially an answer to my main question. Now I just hope can get some more specific feedback about Webtatic repo in particular, otherwise I think will follow your advise, which is also my gut feeling and what I always did until now. (Like you, its about PHP version...)
– Niki
Apr 4 '16 at 19:03
add a comment |
Back when I first started as a Linux admin 8 years ago I used to use a popular third party repository to upgrade my LAMP stack. It was run by a single individual. One of the primary reasons was developers pressuring me for a newer version of PHP than what came with RHEL 5. It ended up biting me.
The person abandoned the repositories so I was no longer getting security updates, but I also could not remove all the newer packages and go back to the RHEL packages due to the RHEL version of PHP being from too old a branch. Moving to that repository's LAMP stack touched at-least half a dozen packages or more. So, maintaining those packages and recompiling them all by hand from time to time would be a major PITA.
You also lose the ability to use the OS vendor's security advisories regarding CVE vulnerabilities to determine whether your system is or is not vulnerable to a certain exploit for those packages. This proved to be a major problem for me years later, even though I would have never anticipated at the time.
So, in addition to having trust in the maintainers integrity and technical skills, you have to ask yourself whether you trust them not to move on to a new job that wont allow them to maintain the repository, or get married and have kids and no longer have time, etc....
Since then I have been very skittish about using any third party repositories, especially those that only have one person running them.
Back when I first started as a Linux admin 8 years ago I used to use a popular third party repository to upgrade my LAMP stack. It was run by a single individual. One of the primary reasons was developers pressuring me for a newer version of PHP than what came with RHEL 5. It ended up biting me.
The person abandoned the repositories so I was no longer getting security updates, but I also could not remove all the newer packages and go back to the RHEL packages due to the RHEL version of PHP being from too old a branch. Moving to that repository's LAMP stack touched at-least half a dozen packages or more. So, maintaining those packages and recompiling them all by hand from time to time would be a major PITA.
You also lose the ability to use the OS vendor's security advisories regarding CVE vulnerabilities to determine whether your system is or is not vulnerable to a certain exploit for those packages. This proved to be a major problem for me years later, even though I would have never anticipated at the time.
So, in addition to having trust in the maintainers integrity and technical skills, you have to ask yourself whether you trust them not to move on to a new job that wont allow them to maintain the repository, or get married and have kids and no longer have time, etc....
Since then I have been very skittish about using any third party repositories, especially those that only have one person running them.
edited Aug 3 '18 at 11:29
Community♦
1
1
answered Apr 4 '16 at 1:53
digitaladdictionsdigitaladdictions
1,1781925
1,1781925
Thanks! These are all the questions I am already asking my self, however your experience is partially an answer to my main question. Now I just hope can get some more specific feedback about Webtatic repo in particular, otherwise I think will follow your advise, which is also my gut feeling and what I always did until now. (Like you, its about PHP version...)
– Niki
Apr 4 '16 at 19:03
add a comment |
Thanks! These are all the questions I am already asking my self, however your experience is partially an answer to my main question. Now I just hope can get some more specific feedback about Webtatic repo in particular, otherwise I think will follow your advise, which is also my gut feeling and what I always did until now. (Like you, its about PHP version...)
– Niki
Apr 4 '16 at 19:03
Thanks! These are all the questions I am already asking my self, however your experience is partially an answer to my main question. Now I just hope can get some more specific feedback about Webtatic repo in particular, otherwise I think will follow your advise, which is also my gut feeling and what I always did until now. (Like you, its about PHP version...)
– Niki
Apr 4 '16 at 19:03
Thanks! These are all the questions I am already asking my self, however your experience is partially an answer to my main question. Now I just hope can get some more specific feedback about Webtatic repo in particular, otherwise I think will follow your advise, which is also my gut feeling and what I always did until now. (Like you, its about PHP version...)
– Niki
Apr 4 '16 at 19:03
add a comment |
Remi is the standard for latest builds of PHP for RHEL. He is a long established and reliable source for RPM packages that's being actively maintained and includes as many relevant packages as possible.
The webtatic source is unknown and untrusted. It shouldn't be used at all.
I found it running on a legacy system. It had a serious memory leak in it. I replaced it with Remi, exactly the same PHP version and suddenly everything's running smoothly. I don't think it's even a stable compile.
add a comment |
Remi is the standard for latest builds of PHP for RHEL. He is a long established and reliable source for RPM packages that's being actively maintained and includes as many relevant packages as possible.
The webtatic source is unknown and untrusted. It shouldn't be used at all.
I found it running on a legacy system. It had a serious memory leak in it. I replaced it with Remi, exactly the same PHP version and suddenly everything's running smoothly. I don't think it's even a stable compile.
add a comment |
Remi is the standard for latest builds of PHP for RHEL. He is a long established and reliable source for RPM packages that's being actively maintained and includes as many relevant packages as possible.
The webtatic source is unknown and untrusted. It shouldn't be used at all.
I found it running on a legacy system. It had a serious memory leak in it. I replaced it with Remi, exactly the same PHP version and suddenly everything's running smoothly. I don't think it's even a stable compile.
Remi is the standard for latest builds of PHP for RHEL. He is a long established and reliable source for RPM packages that's being actively maintained and includes as many relevant packages as possible.
The webtatic source is unknown and untrusted. It shouldn't be used at all.
I found it running on a legacy system. It had a serious memory leak in it. I replaced it with Remi, exactly the same PHP version and suddenly everything's running smoothly. I don't think it's even a stable compile.
edited Apr 16 at 15:54
answered Mar 26 at 18:00
jgmjgmjgmjgm
1113
1113
add a comment |
add a comment |
In general, unless you know there's a feature you actually seriously need and actually can't live without (as many people will believe they can't .. until it's a choice between 'old' or nothing) then stick with the vendor packages.
Teach your webdevs why a branch isn't a stagnant snapshot, and show them - PHP is a great one for this - how upstream rebasing brings in far more bugs; and how in many cases the response time for a backport around a security issue is actually faster and more reliably delivered by a distro in their maintained branch (because it's someone's priority and job) than in the upstream OEM version.
You may be the one who actually succeeds, and you owe it to the rest of us to try ;-)
PHP is a pretty poor example for this: We almost always need point releases for bugfixes, but the distros do not provide them. They have good reason, of course. But having the repos available where we can get bugfixes in point releases is extremely helpful.
– Michael Hampton♦
Aug 3 '18 at 15:02
We use different distros, I suspect. I haven't seen a lack of bugfix and security updates in PHP, even though the distro has branched at a certain upstream version and the version appears locked to the layman. rpm -q php --changelog shows weekly updates with bugfixes and security updates aplenty. I'm sorry if you're not getting the same mileage :-(
– user2066657
Aug 3 '18 at 15:41
Definitely different distros. I don't see that in PHP on RHEL 7.5 or CentOS 7.5. Fedora has updated PHP packages though, and generally doesn't have this problem. Fortunately Remi Collet, the Red Hat employee who builds RHEL's PHP packages, also maintains repos with PHP point releases. Which is part of the reason Red Hat hired him.
– Michael Hampton♦
Aug 3 '18 at 15:49
Hmm. I was looking at the RH/Centos ones. I can't explain why you're not seeing the same --changelog I am, and I'm sorry to see it. I wish Remi would update SCL a bit more. I'm seeing slowdowns there (7.1.8 and not even a package release to update). I was actually mostly convinced he'd moved on, this morning. If only Fedora wasn't a mayfly.
– user2066657
Aug 3 '18 at 20:53
Really? I don't know what packages you are looking at but I see no updates since php-5.4.16-45.el7. Maybe you're looking at something from a software collection? Speaking of which, SCLs are on a bit slower pace. If you actually want PHP releases as they happen, hit up rpms.remirepo.net
– Michael Hampton♦
Aug 3 '18 at 20:56
|
show 2 more comments
In general, unless you know there's a feature you actually seriously need and actually can't live without (as many people will believe they can't .. until it's a choice between 'old' or nothing) then stick with the vendor packages.
Teach your webdevs why a branch isn't a stagnant snapshot, and show them - PHP is a great one for this - how upstream rebasing brings in far more bugs; and how in many cases the response time for a backport around a security issue is actually faster and more reliably delivered by a distro in their maintained branch (because it's someone's priority and job) than in the upstream OEM version.
You may be the one who actually succeeds, and you owe it to the rest of us to try ;-)
PHP is a pretty poor example for this: We almost always need point releases for bugfixes, but the distros do not provide them. They have good reason, of course. But having the repos available where we can get bugfixes in point releases is extremely helpful.
– Michael Hampton♦
Aug 3 '18 at 15:02
We use different distros, I suspect. I haven't seen a lack of bugfix and security updates in PHP, even though the distro has branched at a certain upstream version and the version appears locked to the layman. rpm -q php --changelog shows weekly updates with bugfixes and security updates aplenty. I'm sorry if you're not getting the same mileage :-(
– user2066657
Aug 3 '18 at 15:41
Definitely different distros. I don't see that in PHP on RHEL 7.5 or CentOS 7.5. Fedora has updated PHP packages though, and generally doesn't have this problem. Fortunately Remi Collet, the Red Hat employee who builds RHEL's PHP packages, also maintains repos with PHP point releases. Which is part of the reason Red Hat hired him.
– Michael Hampton♦
Aug 3 '18 at 15:49
Hmm. I was looking at the RH/Centos ones. I can't explain why you're not seeing the same --changelog I am, and I'm sorry to see it. I wish Remi would update SCL a bit more. I'm seeing slowdowns there (7.1.8 and not even a package release to update). I was actually mostly convinced he'd moved on, this morning. If only Fedora wasn't a mayfly.
– user2066657
Aug 3 '18 at 20:53
Really? I don't know what packages you are looking at but I see no updates since php-5.4.16-45.el7. Maybe you're looking at something from a software collection? Speaking of which, SCLs are on a bit slower pace. If you actually want PHP releases as they happen, hit up rpms.remirepo.net
– Michael Hampton♦
Aug 3 '18 at 20:56
|
show 2 more comments
In general, unless you know there's a feature you actually seriously need and actually can't live without (as many people will believe they can't .. until it's a choice between 'old' or nothing) then stick with the vendor packages.
Teach your webdevs why a branch isn't a stagnant snapshot, and show them - PHP is a great one for this - how upstream rebasing brings in far more bugs; and how in many cases the response time for a backport around a security issue is actually faster and more reliably delivered by a distro in their maintained branch (because it's someone's priority and job) than in the upstream OEM version.
You may be the one who actually succeeds, and you owe it to the rest of us to try ;-)
In general, unless you know there's a feature you actually seriously need and actually can't live without (as many people will believe they can't .. until it's a choice between 'old' or nothing) then stick with the vendor packages.
Teach your webdevs why a branch isn't a stagnant snapshot, and show them - PHP is a great one for this - how upstream rebasing brings in far more bugs; and how in many cases the response time for a backport around a security issue is actually faster and more reliably delivered by a distro in their maintained branch (because it's someone's priority and job) than in the upstream OEM version.
You may be the one who actually succeeds, and you owe it to the rest of us to try ;-)
answered Aug 2 '18 at 20:01
user2066657user2066657
270110
270110
PHP is a pretty poor example for this: We almost always need point releases for bugfixes, but the distros do not provide them. They have good reason, of course. But having the repos available where we can get bugfixes in point releases is extremely helpful.
– Michael Hampton♦
Aug 3 '18 at 15:02
We use different distros, I suspect. I haven't seen a lack of bugfix and security updates in PHP, even though the distro has branched at a certain upstream version and the version appears locked to the layman. rpm -q php --changelog shows weekly updates with bugfixes and security updates aplenty. I'm sorry if you're not getting the same mileage :-(
– user2066657
Aug 3 '18 at 15:41
Definitely different distros. I don't see that in PHP on RHEL 7.5 or CentOS 7.5. Fedora has updated PHP packages though, and generally doesn't have this problem. Fortunately Remi Collet, the Red Hat employee who builds RHEL's PHP packages, also maintains repos with PHP point releases. Which is part of the reason Red Hat hired him.
– Michael Hampton♦
Aug 3 '18 at 15:49
Hmm. I was looking at the RH/Centos ones. I can't explain why you're not seeing the same --changelog I am, and I'm sorry to see it. I wish Remi would update SCL a bit more. I'm seeing slowdowns there (7.1.8 and not even a package release to update). I was actually mostly convinced he'd moved on, this morning. If only Fedora wasn't a mayfly.
– user2066657
Aug 3 '18 at 20:53
Really? I don't know what packages you are looking at but I see no updates since php-5.4.16-45.el7. Maybe you're looking at something from a software collection? Speaking of which, SCLs are on a bit slower pace. If you actually want PHP releases as they happen, hit up rpms.remirepo.net
– Michael Hampton♦
Aug 3 '18 at 20:56
|
show 2 more comments
PHP is a pretty poor example for this: We almost always need point releases for bugfixes, but the distros do not provide them. They have good reason, of course. But having the repos available where we can get bugfixes in point releases is extremely helpful.
– Michael Hampton♦
Aug 3 '18 at 15:02
We use different distros, I suspect. I haven't seen a lack of bugfix and security updates in PHP, even though the distro has branched at a certain upstream version and the version appears locked to the layman. rpm -q php --changelog shows weekly updates with bugfixes and security updates aplenty. I'm sorry if you're not getting the same mileage :-(
– user2066657
Aug 3 '18 at 15:41
Definitely different distros. I don't see that in PHP on RHEL 7.5 or CentOS 7.5. Fedora has updated PHP packages though, and generally doesn't have this problem. Fortunately Remi Collet, the Red Hat employee who builds RHEL's PHP packages, also maintains repos with PHP point releases. Which is part of the reason Red Hat hired him.
– Michael Hampton♦
Aug 3 '18 at 15:49
Hmm. I was looking at the RH/Centos ones. I can't explain why you're not seeing the same --changelog I am, and I'm sorry to see it. I wish Remi would update SCL a bit more. I'm seeing slowdowns there (7.1.8 and not even a package release to update). I was actually mostly convinced he'd moved on, this morning. If only Fedora wasn't a mayfly.
– user2066657
Aug 3 '18 at 20:53
Really? I don't know what packages you are looking at but I see no updates since php-5.4.16-45.el7. Maybe you're looking at something from a software collection? Speaking of which, SCLs are on a bit slower pace. If you actually want PHP releases as they happen, hit up rpms.remirepo.net
– Michael Hampton♦
Aug 3 '18 at 20:56
PHP is a pretty poor example for this: We almost always need point releases for bugfixes, but the distros do not provide them. They have good reason, of course. But having the repos available where we can get bugfixes in point releases is extremely helpful.
– Michael Hampton♦
Aug 3 '18 at 15:02
PHP is a pretty poor example for this: We almost always need point releases for bugfixes, but the distros do not provide them. They have good reason, of course. But having the repos available where we can get bugfixes in point releases is extremely helpful.
– Michael Hampton♦
Aug 3 '18 at 15:02
We use different distros, I suspect. I haven't seen a lack of bugfix and security updates in PHP, even though the distro has branched at a certain upstream version and the version appears locked to the layman. rpm -q php --changelog shows weekly updates with bugfixes and security updates aplenty. I'm sorry if you're not getting the same mileage :-(
– user2066657
Aug 3 '18 at 15:41
We use different distros, I suspect. I haven't seen a lack of bugfix and security updates in PHP, even though the distro has branched at a certain upstream version and the version appears locked to the layman. rpm -q php --changelog shows weekly updates with bugfixes and security updates aplenty. I'm sorry if you're not getting the same mileage :-(
– user2066657
Aug 3 '18 at 15:41
Definitely different distros. I don't see that in PHP on RHEL 7.5 or CentOS 7.5. Fedora has updated PHP packages though, and generally doesn't have this problem. Fortunately Remi Collet, the Red Hat employee who builds RHEL's PHP packages, also maintains repos with PHP point releases. Which is part of the reason Red Hat hired him.
– Michael Hampton♦
Aug 3 '18 at 15:49
Definitely different distros. I don't see that in PHP on RHEL 7.5 or CentOS 7.5. Fedora has updated PHP packages though, and generally doesn't have this problem. Fortunately Remi Collet, the Red Hat employee who builds RHEL's PHP packages, also maintains repos with PHP point releases. Which is part of the reason Red Hat hired him.
– Michael Hampton♦
Aug 3 '18 at 15:49
Hmm. I was looking at the RH/Centos ones. I can't explain why you're not seeing the same --changelog I am, and I'm sorry to see it. I wish Remi would update SCL a bit more. I'm seeing slowdowns there (7.1.8 and not even a package release to update). I was actually mostly convinced he'd moved on, this morning. If only Fedora wasn't a mayfly.
– user2066657
Aug 3 '18 at 20:53
Hmm. I was looking at the RH/Centos ones. I can't explain why you're not seeing the same --changelog I am, and I'm sorry to see it. I wish Remi would update SCL a bit more. I'm seeing slowdowns there (7.1.8 and not even a package release to update). I was actually mostly convinced he'd moved on, this morning. If only Fedora wasn't a mayfly.
– user2066657
Aug 3 '18 at 20:53
Really? I don't know what packages you are looking at but I see no updates since php-5.4.16-45.el7. Maybe you're looking at something from a software collection? Speaking of which, SCLs are on a bit slower pace. If you actually want PHP releases as they happen, hit up rpms.remirepo.net
– Michael Hampton♦
Aug 3 '18 at 20:56
Really? I don't know what packages you are looking at but I see no updates since php-5.4.16-45.el7. Maybe you're looking at something from a software collection? Speaking of which, SCLs are on a bit slower pace. If you actually want PHP releases as they happen, hit up rpms.remirepo.net
– Michael Hampton♦
Aug 3 '18 at 20:56
|
show 2 more comments
Thanks for contributing an answer to Server Fault!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f767504%2fwho-is-the-behind-webtatic-repository-and-do-you-trust-it%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
I would note that there are at least two very different levels of trust: as a developer, I care mainly if the packages are clean (not altered maliciously) and reasonably up-to-date. It is as a sysadmin that I care enormously about long term support, and longevity of the maintainers.
– jhominal
Apr 5 '17 at 17:35
Correct. Here I ask as sysadmin, changing server OS/teach only every 5 or more years
– Niki
Apr 5 '17 at 21:51
Both as a system admin and developer it's important to use decent sources of builds. Otherwise you'll risk having problems such as bad builds causing bugs or limitations in feature sets, etc. A bad source might be distributing packages without things like -O2 and you'll be totalyl clueless as to it.
– jgmjgm
Apr 16 at 15:57