Re:dropped that fool and the systemd it rode in on
on
Fedora 21 Released
·
· Score: 1
Welcome to traditional BSD partition tables... Dedicated/var/log partitions ftw.
Re:dropped that fool and the systemd it rode in on
on
Fedora 21 Released
·
· Score: 1
> "It's readily apparent you haven't even used Fedora in years."
Actually, I've been grumbling about it since Fedora 15, but I just never gave up grumbling about it because I am forced to use it for my work. I currently run F20 on a workstation for managing various systems both in the cloud and managed in a local series of VMWare clusters. I use Fedora because it helps me maintain a step ahead of the stuff coming "down the pipe" to Redhat.
> "but at least for enterprise distros like RHEL, standard syslogs are pretty much required"
Rsyslog is quite literally the ONLY reason several of my customers can even run RHEL7... It's amazing how many Developers/Engineers/Admins base their scripts, reports, monitoring and other functions off of log output.
In the end, I am just waiting for the market to "speak" as to whether they accept RHEL7... I am required to give it a year to know for sure. If I had my way though, I'd go back to Slackware or FreeBSD, but that's not my sole choice. As a closing, fvck deps... that is what I feel about anything from 0pointer.
Re:dropped that fool and the systemd it rode in on
on
Fedora 21 Released
·
· Score: 2
> "While it's not impossible for journald'd logs to get corrupted, it's no more likely than most other files in the filesystem."
*cough* BULLSHIT! *cough*
- Laptop failure to resume from suspend = corrupted logs - Power loss or hard off on systems = corrupted logs - Too long a log retention = corrupted logs
From an amazon cloud server running RHEL7 last couple of weeks: File corruption detected at/var/log/journal/2dd5724e1e1542fc9a4aa75nov26cc150/system@f0282a3cd24344648a0bbe3a801ead66-000000000001b5d4-0004cfd1dbb89d83.journal:191117416 (of 233118464, 82%).
journalctl absolutely needs to be improved to handle corrupt logs better... maybe something to repair them instead of switching to "clean" them?
Hurray! More 0pointer dependencies that need rpm -e --nodeps on!
If it weren't for stable RHEL6.X and XFCE, I'd have dumped Fedora back in version 15, but this latest version 21 (codename/dev/null ) is really making me contemplate it again.
Anyone got a suggestion for a distro without so much dep crap?
It's my understanding that the app maintainers do not want to maintain both initd and systemd compatibility at the same time... Extra work for little reward.
I, like many other sysadmins out there who do some level of coding to maintain large swaths of servers dislike the change to systemd on the premise that this wasn't a "phased" implementation. The rebuttal on the systemd camp is that it cannot be phased in and too bad, so you have to rewrite a few scripts and make a "few" changes to your administration processes. They do not realize it is more than just a few changes for many though and I think that's where much of the anger lay boiling... lack of empathy on either side.
I am not a security adviser, so I cannot say for sure which ones they were referring to and the only info they gave me was a list of about 13 x US-CERN, NVD and Canonical advisories regarding the exploitation of systemd through various methods. These were not noted as "fixed" either and 4 are listed as "Medium".
We dropped $2.2M on 2 half populated IBM Power 7 780's (redundant VIOS with IBM's tailored 42U cabinets) in 2012 and are running approximately 239 AIX 6+ & 7.1 LPARs for many of our Financial and Business Continuity Applications. LPAR isn't quite as advanced as VMWare, but it is getting there (no more stupid 4 lines of lpar commands for simple resource management/adjustment). Compared to what we spent on the p5 series years ago, we paid 40% less for our Power 7's. Power system prices have come down A LOT over the last 3 years though and I would professionally recommend checking them out if you need some SystemV style stability.
Anyway, we WERE hoping to move away from AIX to RHEL so we did not need to have two separate UNIX SysAdmin groups, but RHEL7 kinda threw that out the window for us sadly. Personally, I am less bemoaning of systemd than I am over the plethora of other MANDATORY changes they decided to dump on the customer all at once. It affects me and my team directly whereas the systemd thing effects my vendors and their applications.
A lot of what I listed was directly from the RHEL Customer Portal article and it was intended to illustrate the number of changes, but none with any particular order of importance or grief.
For my team, the grievances begin with the slurry of ctl command changes like (but not limited to the following off the top of my head):
rhn_register > subscription-manager system-config-* > gnome-control-center (Who installs gnome on a server?!?!) chkconfig/service/runlevel/init/shutdown/halt/inittab > systemctl system-config-date > timedatectl vi/var/log/ journalctl parted > gdisk ifconfig/network/hosts/dns/eth > nmcli netstat > ss
Our vendors who have explicitly stated they will not support systemd in any way (due to +Priv, DoS and bypass issues/concerns) have stated that they recommend either staying with RHEL6 & Oracle Linux 6 until it is no longer supported or switching to AIX or FreeBSD. Two of these vendors are financial software suites, one is a Point of Sale system and the other is a CRM Suite that "may support it in the future". What the other vendors plan on recommending is still TBD for them. Simply put though, many companies are more invested in their applications than any flavor of *NIX.
>>I don't know about how you write scripts, but I find it amazing that a majority of them has to be rewritten.
Have you not seen the number of changes in management, monitoring & configuration commands made within RHEL7? Seriously, it borders on being a completely new distro the way everything has been retooled. Many of our SysAdmin scripts are written in Perl & Bash with remote get for everything from deployment to monitoring and analysis (netstat? gone. ifconfig? redirected. iptables? gone. lsof? switches changed. chkconfig? redirected. So many more...).
Let me see, the top 3 I cannot do anymore include: - More than half of my companies preferred vendor applications will not run on systemd (some of which will never support it) - Majority of in-house scripts need to be rewritten - Kickstart now REQUIRED since they removed "Full Custom Install"
The growing list of complaints are raising flags in my company so much so that we are looking at outright dumping Redhat and we have been a dedicated Redhat Enterprise customer since 1997. RHEL7 has ZERO TCO for everyone I've spoken with... Retraining, retooling, reconfiguring and reorganizing are absurd.
I have no idea why Redhat made so many changes in their most recent release, but it is so vast that it may as well be a completely new distro. To name a FEW:
Anaconda RHEL installer completely redesigned
Legacy GRUB boot loader replaced by GRUB2
Procedure for bypassing root password prompt at boot completely different
SysV init system and all related tools replaced by systemd
ext4 replaced by xfs as default filesystem type
Directories/bin,/sbin,/liband/lib64are now all under the/usrdirectory
Network interfaces have a new naming scheme based on physical device location (e.g., eth0might become enp0s3)
ntpdreplaced by chronydas the default network time protocol daemon
GNOME2 replaced by GNOME3 as default desktop environment
System registration and subscription now handled exclusively with Red Hat Subscription Management (RHSM)
MySQL replaced by Mariadb
tgtdreplaced by targetcli
High Availability Add-On: RGManager removed as resource-management option (in favor of Pacemaker)
ifconfigand routecommands are further deprecated in favor of ip
netstatfurther deprecated in favor of ss
System user UID range extended from 0-499 to 0-999
locateno longer available by default; (available as mlocatepackage)
nc(netcat) replaced by nmap-ncat
Systemd is pain to use for me and feels backwards... I find troubleshooting processes with it to be more frustrating than anything else Redhat has done in the past 20 years... Well, almost.
Nope! Nothing to hear since it was "an artificial atom". Meaning, they were not really even listening in the first place, but rather determining if it could be done.
I always wondered why we have not advanced to the point of using our DNA or similar as a PIN. Exhaled breath condensate is a non-invasive method for detecting a wide number of molecules as well as genomic DNA in the airways and could easily be a source of information usable as an ID Verification technique.
Back in the 90's when places like SharkyExtreme.com, jc-news.com, HardOCP.com and Tomshardware.com were "it", Anand Lai made a name for himself for his more than truthful video reviews. It was a new take on things with this guy Anand, sometimes sitting on a rock outside, chatting about computers.
I still trust much of the content on his site, but worry it'll go the way of sharkyextreme now. Perhaps legitreviews or some other can fill that void without Anand around.
Thank you for helping millions of us make good choices over the years Anand, I wish you the best!
In San Diego, California, USA where I live we have an initiative to build the worlds largest Desalination plant of its kind, yet are plagued by the state constantly forcing setbacks. Partially EPA related, partially playing card material for the Governor Jerry Brown.
China has a similar design going into effect right now and achieving an effective and profitable desalination design. Still, it comes down to two things:
1) Economy of scale in desalination (how much) There is currently a break point in efficiency/pollution whereby anything under 100 gallons/hr. can easily be cost efficient. Anything beyond that has to this point, cost more than importing it. San Diego's DeSal is attempting to create a new break point @ the high-end of production however (2 million gallons per hour) and it remains to be seen if it will work. Source
2) Supply & Demand When it rains, why spend money on desalination when you get it from the sky? As California's Jerry Brown once stated: "When it rains here in California, it might as well be raining money." Jerry Brown, 1982.
The biggest concerns from the EPA about Desalination technologies come down to what happens to the brine sludge byproducts and the cost to run. Well, San Diego's option is actually rather efficient and its cost only slightly higher than importing water. A cost we can live with, but the fight continues on another front! The sludge has become the new controversy that the EPA and PETA girls are all upset about.
Right now, most desal plants average about ~1 metric ton of sludge per ~12 million litres of fresh drinking water. So what happens to it? - Australia, Africa, Saudi Arabia and the UK bury it. - Ghana, Egypt, Nigeria and a few other African nations with Oil reserves are using it as part of their Oil extraction method - USA, Japan and Greece currently use it for industrial use as soda ash and sodium bicarbinate - Japan and Australia are currently looking to use it for cement compound, bricks and building materials
In summary, it certainly is NOT pumped back into the Ocean as much as it was even 5 years ago, but the EPA is still "concerned". We just cannot seem to win. Another technology being deployed RIGHT NOW will actually make use of it... ALL of it. WaterFX, a new company on the scene (relatively) has a solution to the amount of sludge that results in 93% of the water becoming palatable. With only 7% byproduct being "sludge salt", it is converted directly into Soda ash and Sodium Bicarbonate and used for: Fire extinguishers, Cooking, Neutralization of acids and bases, Medical uses, Personal hygiene, Cleaning agents, Biopesticides, Cattle feed supplements, Glass making, Pool chemicals, Water softeners, Laundry detergents and a ton of other uses.
None the less, we have to drudge through the political process to get anything done here in California, which unfortunately will take years.
VERY nice radio! I have a YAESU FT-60 144/430MHz w/ 2meter/440MHz magnetic dualband antenna that I take out with me for emergencies and chatting with nearby hammers, but something like a Uni Radio might actually be a good idea (plus it sounds like it could be tweaked for higher frequencies). Thanks for that!
My issue with getting ammo boxes is that they are heavy. Let's assume your situation where, heaven forbid my room comes down and smashes down on top of my closet. The likelihood of being able to even gain access to that area, let alone pull out metal boxes is pretty low imo. I lived through Northridge in 1994 and saw some pretty $%!$ed up homes, but 2 things always seemed to be accessible from my recollections: Garage contents and understair closets. Rubbermaids are not the best, I'll agree with that, but they are airtight and cost efficient.
As for the batteries, I'm just a cheapskate in that arena. I invested heavily into Energizer rechargeables and not all of them are LiOn, but the fact that I can put them into a Solar Charging station and let it sit all day until nightfall when I need them most is invaluable in the event of an emergency. As they charge less however, I replace them with LiOn's however.
Slashdot Mirror
Welcome to traditional BSD partition tables... Dedicated /var/log partitions ftw.
> "It's readily apparent you haven't even used Fedora in years."
Actually, I've been grumbling about it since Fedora 15, but I just never gave up grumbling about it because I am forced to use it for my work. I currently run F20 on a workstation for managing various systems both in the cloud and managed in a local series of VMWare clusters. I use Fedora because it helps me maintain a step ahead of the stuff coming "down the pipe" to Redhat.
> "but at least for enterprise distros like RHEL, standard syslogs are pretty much required"
Rsyslog is quite literally the ONLY reason several of my customers can even run RHEL7... It's amazing how many Developers/Engineers/Admins base their scripts, reports, monitoring and other functions off of log output.
In the end, I am just waiting for the market to "speak" as to whether they accept RHEL7... I am required to give it a year to know for sure. If I had my way though, I'd go back to Slackware or FreeBSD, but that's not my sole choice. As a closing, fvck deps... that is what I feel about anything from 0pointer.
> "While it's not impossible for journald'd logs to get corrupted, it's no more likely than most other files in the filesystem."
*cough* BULLSHIT! *cough*
- Laptop failure to resume from suspend = corrupted logs
- Power loss or hard off on systems = corrupted logs
- Too long a log retention = corrupted logs
From an amazon cloud server running RHEL7 last couple of weeks: /var/log/journal/2dd5724e1e1542fc9a4aa75nov26cc150/system@f0282a3cd24344648a0bbe3a801ead66-000000000001b5d4-0004cfd1dbb89d83.journal:191117416 (of 233118464, 82%).
File corruption detected at
journalctl absolutely needs to be improved to handle corrupt logs better... maybe something to repair them instead of switching to "clean" them?
Hurray! More 0pointer dependencies that need rpm -e --nodeps on!
If it weren't for stable RHEL6.X and XFCE, I'd have dumped Fedora back in version 15, but this latest version 21 (codename /dev/null ) is really making me contemplate it again.
Anyone got a suggestion for a distro without so much dep crap?
Sounds like the Redhat/Fedora boys...
It's my understanding that the app maintainers do not want to maintain both initd and systemd compatibility at the same time... Extra work for little reward.
I, like many other sysadmins out there who do some level of coding to maintain large swaths of servers dislike the change to systemd on the premise that this wasn't a "phased" implementation. The rebuttal on the systemd camp is that it cannot be phased in and too bad, so you have to rewrite a few scripts and make a "few" changes to your administration processes. They do not realize it is more than just a few changes for many though and I think that's where much of the anger lay boiling... lack of empathy on either side.
Everything in this article is based on presumption and speculation.
They did that once already in the UK back in 1997... Still washing up to this day
http://www.bbc.com/news/magazi...
Pfft... I just use webferret from 1997, it bundles up all those fancy search engines into one!
I am not a security adviser, so I cannot say for sure which ones they were referring to and the only info they gave me was a list of about 13 x US-CERN, NVD and Canonical advisories regarding the exploitation of systemd through various methods. These were not noted as "fixed" either and 4 are listed as "Medium".
That list was FROM Redhat, not a troll of any kind... just a list. Sheesh.
We dropped $2.2M on 2 half populated IBM Power 7 780's (redundant VIOS with IBM's tailored 42U cabinets) in 2012 and are running approximately 239 AIX 6+ & 7.1 LPARs for many of our Financial and Business Continuity Applications. LPAR isn't quite as advanced as VMWare, but it is getting there (no more stupid 4 lines of lpar commands for simple resource management/adjustment). Compared to what we spent on the p5 series years ago, we paid 40% less for our Power 7's. Power system prices have come down A LOT over the last 3 years though and I would professionally recommend checking them out if you need some SystemV style stability.
Anyway, we WERE hoping to move away from AIX to RHEL so we did not need to have two separate UNIX SysAdmin groups, but RHEL7 kinda threw that out the window for us sadly. Personally, I am less bemoaning of systemd than I am over the plethora of other MANDATORY changes they decided to dump on the customer all at once. It affects me and my team directly whereas the systemd thing effects my vendors and their applications.
A lot of what I listed was directly from the RHEL Customer Portal article and it was intended to illustrate the number of changes, but none with any particular order of importance or grief.
For my team, the grievances begin with the slurry of ctl command changes like (but not limited to the following off the top of my head):
rhn_register > subscription-manager /var/log/ journalctl
system-config-* > gnome-control-center (Who installs gnome on a server?!?!)
chkconfig/service/runlevel/init/shutdown/halt/inittab > systemctl
system-config-date > timedatectl
vi
parted > gdisk
ifconfig/network/hosts/dns/eth > nmcli
netstat > ss
And Apple Xservers were SUCH great performers... /sarcasm
>>So, what alternative are you looking at?
Our vendors who have explicitly stated they will not support systemd in any way (due to +Priv, DoS and bypass issues/concerns) have stated that they recommend either staying with RHEL6 & Oracle Linux 6 until it is no longer supported or switching to AIX or FreeBSD. Two of these vendors are financial software suites, one is a Point of Sale system and the other is a CRM Suite that "may support it in the future". What the other vendors plan on recommending is still TBD for them. Simply put though, many companies are more invested in their applications than any flavor of *NIX.
>>I don't know about how you write scripts, but I find it amazing that a majority of them has to be rewritten.
Have you not seen the number of changes in management, monitoring & configuration commands made within RHEL7? Seriously, it borders on being a completely new distro the way everything has been retooled. Many of our SysAdmin scripts are written in Perl & Bash with remote get for everything from deployment to monitoring and analysis (netstat? gone. ifconfig? redirected. iptables? gone. lsof? switches changed. chkconfig? redirected. So many more...).
> What can't I do anymore?
Let me see, the top 3 I cannot do anymore include:
- More than half of my companies preferred vendor applications will not run on systemd (some of which will never support it)
- Majority of in-house scripts need to be rewritten
- Kickstart now REQUIRED since they removed "Full Custom Install"
The growing list of complaints are raising flags in my company so much so that we are looking at outright dumping Redhat and we have been a dedicated Redhat Enterprise customer since 1997. RHEL7 has ZERO TCO for everyone I've spoken with... Retraining, retooling, reconfiguring and reorganizing are absurd.
I have no idea why Redhat made so many changes in their most recent release, but it is so vast that it may as well be a completely new distro. To name a FEW:
Anaconda RHEL installer completely redesigned /bin, /sbin, /liband /lib64are now all under the /usrdirectory
Legacy GRUB boot loader replaced by GRUB2
Procedure for bypassing root password prompt at boot completely different
SysV init system and all related tools replaced by systemd
ext4 replaced by xfs as default filesystem type
Directories
Network interfaces have a new naming scheme based on physical device location (e.g., eth0might become enp0s3)
ntpdreplaced by chronydas the default network time protocol daemon
GNOME2 replaced by GNOME3 as default desktop environment
System registration and subscription now handled exclusively with Red Hat Subscription Management (RHSM)
MySQL replaced by Mariadb
tgtdreplaced by targetcli
High Availability Add-On: RGManager removed as resource-management option (in favor of Pacemaker)
ifconfigand routecommands are further deprecated in favor of ip
netstatfurther deprecated in favor of ss
System user UID range extended from 0-499 to 0-999
locateno longer available by default; (available as mlocatepackage)
nc(netcat) replaced by nmap-ncat
Systemd is pain to use for me and feels backwards... I find troubleshooting processes with it to be more frustrating than anything else Redhat has done in the past 20 years... Well, almost.
Nope! Nothing to hear since it was "an artificial atom". Meaning, they were not really even listening in the first place, but rather determining if it could be done.
I always wondered why we have not advanced to the point of using our DNA or similar as a PIN. Exhaled breath condensate is a non-invasive method for detecting a wide number of molecules as well as genomic DNA in the airways and could easily be a source of information usable as an ID Verification technique.
Pfft... Cirrus Logics were horrible! Everyone who was anyone bought Diamond S3 VLB cards. That is, until the Matrox Mystique came out on PCI!
Back in the 90's when places like SharkyExtreme.com, jc-news.com, HardOCP.com and Tomshardware.com were "it", Anand Lai made a name for himself for his more than truthful video reviews. It was a new take on things with this guy Anand, sometimes sitting on a rock outside, chatting about computers.
I still trust much of the content on his site, but worry it'll go the way of sharkyextreme now. Perhaps legitreviews or some other can fill that void without Anand around.
Thank you for helping millions of us make good choices over the years Anand, I wish you the best!
Seriously,,, If they had to default back to SC4, it shows that SC5 was not a real enough simulator and totally incapable of fielding such a project.
In San Diego, California, USA where I live we have an initiative to build the worlds largest Desalination plant of its kind, yet are plagued by the state constantly forcing setbacks. Partially EPA related, partially playing card material for the Governor Jerry Brown.
China has a similar design going into effect right now and achieving an effective and profitable desalination design. Still, it comes down to two things:
1) Economy of scale in desalination (how much) There is currently a break point in efficiency/pollution whereby anything under 100 gallons/hr. can easily be cost efficient. Anything beyond that has to this point, cost more than importing it. San Diego's DeSal is attempting to create a new break point @ the high-end of production however (2 million gallons per hour) and it remains to be seen if it will work. Source
2) Supply & Demand When it rains, why spend money on desalination when you get it from the sky? As California's Jerry Brown once stated: "When it rains here in California, it might as well be raining money." Jerry Brown, 1982.
The biggest concerns from the EPA about Desalination technologies come down to what happens to the brine sludge byproducts and the cost to run. Well, San Diego's option is actually rather efficient and its cost only slightly higher than importing water. A cost we can live with, but the fight continues on another front! The sludge has become the new controversy that the EPA and PETA girls are all upset about.
Right now, most desal plants average about ~1 metric ton of sludge per ~12 million litres of fresh drinking water. So what happens to it?
- Australia, Africa, Saudi Arabia and the UK bury it.
- Ghana, Egypt, Nigeria and a few other African nations with Oil reserves are using it as part of their Oil extraction method
- USA, Japan and Greece currently use it for industrial use as soda ash and sodium bicarbinate
- Japan and Australia are currently looking to use it for cement compound, bricks and building materials
In summary, it certainly is NOT pumped back into the Ocean as much as it was even 5 years ago, but the EPA is still "concerned". We just cannot seem to win. Another technology being deployed RIGHT NOW will actually make use of it... ALL of it. WaterFX, a new company on the scene (relatively) has a solution to the amount of sludge that results in 93% of the water becoming palatable. With only 7% byproduct being "sludge salt", it is converted directly into Soda ash and Sodium Bicarbonate and used for: Fire extinguishers, Cooking, Neutralization of acids and bases, Medical uses, Personal hygiene, Cleaning agents, Biopesticides, Cattle feed supplements, Glass making, Pool chemicals, Water softeners, Laundry detergents and a ton of other uses.
None the less, we have to drudge through the political process to get anything done here in California, which unfortunately will take years.
Good info, thanks for the clarification!
VERY nice radio! I have a YAESU FT-60 144/430MHz w/ 2meter/440MHz magnetic dualband antenna that I take out with me for emergencies and chatting with nearby hammers, but something like a Uni Radio might actually be a good idea (plus it sounds like it could be tweaked for higher frequencies). Thanks for that!
My issue with getting ammo boxes is that they are heavy. Let's assume your situation where, heaven forbid my room comes down and smashes down on top of my closet. The likelihood of being able to even gain access to that area, let alone pull out metal boxes is pretty low imo. I lived through Northridge in 1994 and saw some pretty $%!$ed up homes, but 2 things always seemed to be accessible from my recollections: Garage contents and understair closets. Rubbermaids are not the best, I'll agree with that, but they are airtight and cost efficient.
As for the batteries, I'm just a cheapskate in that arena. I invested heavily into Energizer rechargeables and not all of them are LiOn, but the fact that I can put them into a Solar Charging station and let it sit all day until nightfall when I need them most is invaluable in the event of an emergency. As they charge less however, I replace them with LiOn's however.