|
Thanks Ants posted:Have a look at It would be kewl, but it would be pretty expensive to send Arduino data around in. By the by--the actual cost of the sending and receiving units (the little port 'holes' you plug the fiber-optic cables into on the equipment) is,,, not cheap. CHEAP ones can be found for $25 each. Most cost $100-$200, and some cost even more. Depending on the speeds. Plus there is some circuitry built-in to the telecom ports that I didn't wanna deal with. I just wanted a one-way line, with a laser or LED on one end and a photodetector on the other. For Arduino-grade sillyness. toslink (usually plastic fiber) is a lot more practical, at least for up to 20-30 meters. There's no good source for DIY end fittings, but cheap & ugly toslink cables cost roughly $1 a meter. But Toslink tx and rx modules are still $10 ~ $20 each, so you have to improvise by cutting up a 1-meter cable ($1.25) and then using each end as a tx or rx unit somehow, and then using butt connectors to attach everything together (toslink butt connectors only cost ~50 cents each). edmund745 fucked around with this message at 18:47 on Aug 11, 2017 |
# ? Aug 11, 2017 18:42 |
|
|
# ? May 27, 2024 03:30 |
|
FC Zoning. Anyone use anything that's not the proprietary Brocade/Cisco tools that are insanely priced? I have a non-trivial zoneset to build... (2 sites, 4 FC switches, vplexes, multiple recoverpoint clusters, 8 storage arrays and about 100 hosts). I currently use excel but certainly simple mapping of groups to rules to generate single initiator, single target zones seems like a problem that was solved in 2004.
|
# ? Oct 24, 2017 03:50 |
|
Well Western Digital bought my vendor. Woo!!!
|
# ? Dec 16, 2017 07:11 |
|
Mr-Spain posted:Well Western Digital bought my vendor. Woo!!! Tegile? That was a while back now. And they were always their largest investors.
|
# ? Dec 16, 2017 19:32 |
|
On more goddamn vm to migrate off the CX4 this weekend and we’re kicking that fucker to the curb. The jr admin wants to take it home, lmao. Have fun getting a 30A circuit installed and your electricity bill doubling!
|
# ? Dec 16, 2017 19:43 |
devmd01 posted:On more goddamn vm to migrate off the CX4 this weekend and we’re kicking that fucker to the curb. Tell them they should light it on fire. Waste of power. Maybe scrounge SFPs to sell on ebay
|
|
# ? Dec 16, 2017 20:47 |
|
KennyG posted:FC Zoning. Ansible and a jinja2 template.
|
# ? Dec 18, 2017 00:18 |
|
This Intel bug is going to be a doozy... Has anyone seen official storage vendor responses yet as a result? Not my blog, but I thought this was a fair summary of things: https://lonesysadmin.net/2018/01/02/intel-cpu-design-flaw-performance-degradation-security-updates/
|
# ? Jan 3, 2018 20:42 |
|
I assume every single Atom-powered network appliance has the same flaw?
|
# ? Jan 3, 2018 20:56 |
|
Yep.
|
# ? Jan 3, 2018 21:04 |
|
Well, since Storage arrays generally don’t run untrusted user code I’m not sure how they would be exploitable.
|
# ? Jan 4, 2018 23:33 |
|
the question of whether edge systems can be goosed by inbound traffic to reveal information from microarchitecture exploits is relevant too A user browsing GiveMeYourData.ru without NoScript enabled is one thing, but an edge security stack getting rowhammered or SPECTRE'D is quite another
|
# ? Jan 4, 2018 23:45 |
|
YOLOsubmarine posted:Well, since Storage arrays generally don’t run untrusted user code I’m not sure how they would be exploitable. Neither do servers (generally). The issue comes when you have the intersection of this with another vulnerability. Suddenly, any exploit that's capable of running unprivileged code becomes a lot more serious. For example, it may be possible to do a credential dump that would allow full privileged access to the array. From there, you may be able to change ACLs on shares to open up access to other processes to syphon off data, delete LUNs, even possibly setup access to existing LUNs to a compromised machine to allow data access. bull3964 fucked around with this message at 23:51 on Jan 4, 2018 |
# ? Jan 4, 2018 23:47 |
|
If someone can break into one of your vms, they'll not only try to creep through your internal network, they'll search through adjacent vms to get credentials and keys that make their network intrusion look far more legitimate and reach further If someone on one of your vdi systems is using a browser, same story
|
# ? Jan 4, 2018 23:54 |
|
bull3964 posted:Neither do servers (generally). None of these things are something that array manufacturers can mitigate. Nobody is going to be using Meltdown or Spectre to read the contents of your array because that’s somewhere between extremely difficult to impossible, whereas using them on the servers and workstations that access the array data is fairly easy. Servers aren’t really the main attack vector either those it’s much easier to run arbitrary code on those than on an array that maintains all of its code and libraries on a small piece of privileged flash and that doesn’t actually have any way to trigger arbitrary code in the first place because program execution controlled by supervisor processors, not users.
|
# ? Jan 5, 2018 00:20 |
|
The point is you don't leave an exploit unpatched because of how remotely unlikely it is that someone may exploit it. That doesn't fly when it comes to mission critical system, especially in certain industries. That's also kinda what got us in the current situation. If you are targeted for an attack, the attack is going to be crafted based on the weaknesses found in the system. Yes, there are softer targets out there, but you don't increase the toolbox unnecessarily. EMC just had an advisory last month where SMB could be exploited on Data Domain for RCE. Gaining access to kernel memory or memory within other user processes makes that RCE a lot more useful.
|
# ? Jan 5, 2018 04:37 |
|
bull3964 posted:The point is you don't leave an exploit unpatched because of how remotely unlikely it is that someone may exploit it.
|
# ? Jan 5, 2018 04:42 |
|
Well, I have to eat crow because Pure just emailed me with a statement saying that because there exists no mechanism for running code on their arrays outside of the main OS, there is no current risk.
|
# ? Jan 5, 2018 05:22 |
|
~~~thread broke~~~
|
# ? Jan 5, 2018 05:28 |
|
YOLOsubmarine posted:None of these things are something that array manufacturers can mitigate. Nobody is going to be using Meltdown or Spectre to read the contents of your array because that’s somewhere between extremely difficult to impossible, whereas using them on the servers and workstations that access the array data is fairly easy.
|
# ? Jan 5, 2018 05:38 |
|
bull3964 posted:The point is you don't leave an exploit unpatched because of how remotely unlikely it is that someone may exploit it. That doesn't fly when it comes to mission critical system, especially in certain industries. That's also kinda what got us in the current situation. NetApp and Nimble have already said they’re not vulnerable, and I’d expect to hear the same from most other storage vendors. This paragraph from the Cisco response pretty much sums up what most of hardware provider response has been: “In order to exploit any of these vulnerabilities, an attacker must be able to run crafted code on an affected device. The majority of Cisco products are closed systems, which do not allow customers to run custom code on the device. Although, the underlying CPU and OS combination in a product may be affected by these vulnerabilities, the majority of Cisco products are closed systems that do not allow customers to run custom code on the device, and thus are not vulnerable. There is no vector to exploit them. Only Cisco devices that are found to allow the customer to execute their customized code side-by-side with the Cisco code on the same microprocessor are considered vulnerable.”
|
# ? Jan 5, 2018 08:27 |
|
Why can't I view the last page of this thread
|
# ? Jan 5, 2018 08:29 |
|
hello from this thread's cache buffer overflow
|
# ? Jan 5, 2018 19:06 |
|
This thread is broken
|
# ? Jan 6, 2018 02:21 |
|
YOLOsubmarine posted:Well, since Storage arrays generally don’t run untrusted user code I’m not sure how they would be exploitable.
|
# ? Jan 7, 2018 20:28 |
|
Posting in the thread to see if more posts fixes it.
|
# ? Jan 7, 2018 21:44 |
|
this is a really good thread
|
# ? Jan 7, 2018 21:48 |
|
Is this real life?
|
# ? Jan 8, 2018 21:14 |
|
RIP thread
|
# ? Jan 8, 2018 21:15 |
|
|
# ? Jan 8, 2018 21:40 |
|
Time for a new thread since this one is broken?
|
# ? Jan 8, 2018 21:45 |
|
|
# ? Jan 8, 2018 21:55 |
|
bull3964 posted:The point is you don't leave an exploit unpatched because of how remotely unlikely it is that someone may exploit it. That doesn't fly when it comes to mission critical system, especially in certain industries. That's also kinda what got us in the current situation.
|
# ? Jan 8, 2018 21:56 |
|
Will posting in this thread let me read it? Stay safe ghost posts!
|
# ? Jan 8, 2018 22:04 |
|
Test
|
# ? Jan 9, 2018 05:31 |
Making sure to post in this dead gay thread to hopefully fix it. Anyone else seeing some vendors trending on their smaller all flash products to lowering total ram for front end cache and allocating that memory for system processes like snapshots, dedup etc? I've seen some specs from a couple vendors. I probably shouldn't have had access to those specs so I'm afraid to post specifics due to NDAs. Figured I'd poll some of you goons I know have some good ties in the storage world.
|
|
# ? Jan 10, 2018 04:55 |
|
https://twitter.com/NZ_BenThomas/status/950271094803480577 totes posted this in the wibbows thread, forgot there is a storage mt as well.
|
# ? Jan 10, 2018 05:37 |
|
im gay but thankfully nobody will ever read this
|
# ? Jan 10, 2018 07:17 |
|
More blood for the blood god
|
# ? Jan 10, 2018 07:18 |
|
|
# ? May 27, 2024 03:30 |
|
thread gay, so what
|
# ? Jan 10, 2018 21:56 |