Samba Server Configuration in Centos 6.2
-
@thanksajdotcom said:
Yes, but what does setting up SAMBA prove? It proves you can setup SAMBA. It proves you have a network connection. It doesn't prove anything more than you already have by testing the disks on a new motherboard and accessing everything locally.
This is very important. The client could easily be left with no working RAID and your senior engineer will claim that he has tested it without having tested anything. He's avoiding knowing his job and hoping to cover up that he doesn't understand what is going on.
-
@Lakshmana said:
@thecreativeone91 said:
The motherboard at one company is not working and it was fired.Now I tested with the motherboard A and configured RAID 1 in hard A1 and A2.Then I tested the hard disk in the other motherboard B and inserted the hard disk A1 and A2.So the RAID is working properly.So I need to suggest them the motherboard to be buyed them.So now I finished checking RAID.But my senior engineer said me to check the SAMBA server also to verify the sharing of DataIs the server suppose to be a file server and you need to setup shares? if so that makes sense. But it is unrelated to checking the raid or motherboard replacement. Infact why would all the config not still be there that was from before the replacement. There should be no reason to reimage with a motherboard replacement (especially of the same model).
-
@thecreativeone91 said:
There should be no reason to reimage with a motherboard replacement (especially of the same model).
Even of a different model since there is no connection between the board and the RAID. Only issue is if the drives re-identify themselves. Same issue you have on every reboot of a Cisco UCS - a great reason to avoid that garbage.
-
@scottalanmiller said:
@thecreativeone91 said:
There should be no reason to reimage with a motherboard replacement (especially of the same model).
Even of a different model since there is no connection between the board and the RAID. Only issue is if the drives re-identify themselves. Same issue you have on every reboot of a Cisco UCS - a great reason to avoid that garbage.
Whaaaaaaaa? I've never seen a drive blow off a profile in UCS. What in the world have you been doing?
-
@PSX_Defector said:
Whaaaaaaaa? I've never seen a drive blow off a profile in UCS. What in the world have you been doing?
I've seen it a lot. VMAX over FCoE to large UCS blade chassis. Drive IDs flipped constantly. One of many, many complications that made the UCS just the crappiest gear I've ever seen a business duped into buying in the last decade.
-
@scottalanmiller said:
@PSX_Defector said:
Whaaaaaaaa? I've never seen a drive blow off a profile in UCS. What in the world have you been doing?
I've seen it a lot. VMAX over FCoE to large UCS blade chassis. Drive IDs flipped constantly. One of many, many complications that made the UCS just the crappiest gear I've ever seen a business duped into buying in the last decade.
Uh Oh. a local datacenter I do contract work with is looking to replace the AS/400's (or whatever they call it now since they keep changing the name) with Cisco UCS gear.
-
@Lakshmana, the point is that if the data is there, the data is there. Proving you can access it over a network vs accessing it locally proves nothing in terms of the reliability of the data. If it's all good from a local connection, sharing it so a Windows system can access it makes it sound like your Engineer 1. doesn't know Linux, and doesn't want to admit it and 2. is too lazy to walk to wherever the physical machine is and sit down in front of it, so he wants to make you run around setting up shares so he doesn't have to leave his desk.
@scottalanmiller is right. You need to find a job you can actually learn something from.
-
@thecreativeone91 said:
Uh Oh. a local datacenter I do contract work with is looking to replace the AS/400's (or whatever they call it now since they keep changing the name) with Cisco UCS gear.
One bad decision after another I see. The IBM i (hopefully they don't actually run on AS/400s from the 1990s) is solid, but a pretty poor business decision. It was obvious that it made no sense for any workload even when it first released. Someone was getting IBM kickbacks. Even IBM doesn't use those. Not even the departments that build them.
Cisco UCS is more of the "proprietary, unnecessarily convoluted" garbage. It requires special knowledge and training with no upsides - and that means risk and cost. I can't even fathom letting Cisco in the door to discuss that stuff. Blades have been a known bad idea from day one. Cisco takes the bad idea of blades to an absurd level.
It blows my mind that any company would let a decision maker choose those and keep their job. I've never heard of anyone come up with a reason to have chosen them. No one ever has a technical benefit and I've never seen a shop that used them and didn't get burned in the end.
-
@scottalanmiller said
I've never heard of anyone come up with a reason to have chosen them. No one ever has a technical benefit and I've never seen a shop that used them and didn't get burned in the end.
That's pretty much my opinion of most anything from Cisco expect their switches. I don't care for their routers.
-
I have to keep my opinions of Cisco in check because I work for one of their biggest support partners. There are people on staff here who WROTE protocols Cisco uses. Dual-CCIE level guys and above.
-
@thanksajdotcom said:
I have to keep my opinions of Cisco in check because I work for one of their biggest support partners. There are people on staff here who WROTE protocols Cisco uses. Dual-CCIE level guys and above.
They used to be the only ones who made decent gear. Now there are plenty of others Juniper etc. yet Cisco still charges a high price for the name of yester year.
-
@scottalanmiller said:
@thecreativeone91 said:
Uh Oh. a local datacenter I do contract work with is looking to replace the AS/400's (or whatever they call it now since they keep changing the name) with Cisco UCS gear.
One bad decision after another I see. The IBM i (hopefully they don't actually run on AS/400s from the 1990s) is solid, but a pretty poor business decision. It was obvious that it made no sense for any workload even when it first released. Someone was getting IBM kickbacks. Even IBM doesn't use those. Not even the departments that build them.
Cisco UCS is more of the "proprietary, unnecessarily convoluted" garbage. It requires special knowledge and training with no upsides - and that means risk and cost. I can't even fathom letting Cisco in the door to discuss that stuff. Blades have been a known bad idea from day one. Cisco takes the bad idea of blades to an absurd level.
It blows my mind that any company would let a decision maker choose those and keep their job. I've never heard of anyone come up with a reason to have chosen them. No one ever has a technical benefit and I've never seen a shop that used them and didn't get burned in the end.
The big red V uses them pretty much exclusively with regards to the eCloud and Hosting product line, both physical and virtual devices and private cloud.
Why bother with FCoE when you can just use the much more stable FC or a much more robust protocol of iSCSI over Ethernet?
That said, I've never seen any problem like that with regards to WWNs and the vCenters. And we had lots of them, like over 1000 of them. Maybe you were using some strange firmware or something else. Sounds more like an implementation issue than a wholesale condemnation of the platform. The big red V may be dumb, but even they can implement it with stability and speed says something else.
-
@thecreativeone91 said:
@thanksajdotcom said:
I have to keep my opinions of Cisco in check because I work for one of their biggest support partners. There are people on staff here who WROTE protocols Cisco uses. Dual-CCIE level guys and above.
They used to be the only ones who made decent gear. Now there are plenty of others Juniper etc. yet Cisco still charges a high price for the name of yester year.
I don't disagree. I just have to be less vocal about that kind of stuff. I'm also working to keep an open mind about everything...bringing a bias like that into a business where that is literally ALL they do is a recipe for disaster.
-
@thecreativeone91 said:
That's pretty much my opinion of most anything from Cisco expect their switches. I don't care for their routers.
True, and after meeting a "Cisco engineer" at a Spicecorps, I lost all of my remaining respect for them and their resellers. The Cisco internal people and the Cisco platinum partner that were there couldn't have passed the Network+ between them. The degree to which they didn't understand networking was staggering - like below home user level. They actually tried to convince us that you needed 14Tb/s fiber to the desktop in order to watch a YouTube video. Yeah, 14 Tb!!! Cisco didn't even make such a product. No one ever has.
They had heard a marketing release that they didn't understand, because they knew no networking, and had attempting to sound intelligent which, of course, always makes you sound stupid. But neither Cisco nor their huge reseller sponsoring the event knew the slightest thing about computers or networking (even though these were the senior engineers sent out to do sales to IT pros) figured out that the things being said were ludicrous. It was like telling us that real estate on the moon was the hottest trend and that if you didn't buy today you'd have nowhere to live by the weekend.
-
@PSX_Defector said:
Why bother with FCoE when you can just use the much more stable FC or a much more robust protocol of iSCSI over Ethernet?
.I wondered the same thing since we had lots of FC coming to them. Something to do with the crappy UCS requirements with their head units.
-
@PSX_Defector said:
Maybe you were using some strange firmware or something else. Sounds more like an implementation issue than a wholesale condemnation of the platform.
That's my biggest condemnation of the platform - it requires a level of skill that datacenters don't have. You need a whole new team just to figure out how to install them, get anything wrong and you are burned. It's complication for the sake of complication. That's all risk and cost that other solutions don't have. And from what I've seen, other, cheaper solutions run better and more stably. So even though the platform probably can be made stable, the cost to do so and the risk of getting it wrong are just unnecessary.
-
@PSX_Defector said:
The big red V may be dumb, but even they can implement it with stability and speed says something else.
Only that they throw money at it. Or use it in a specific way that works. Or happen to be on firmware that does what is needed.
Cisco acknowledged the problem, but didn't have a fix for it.
-
-
@thanksajdotcom said:
I have to keep my opinions of Cisco in check because I work for one of their biggest support partners. There are people on staff here who WROTE protocols Cisco uses. Dual-CCIE level guys and above.
Every reseller claims this stuff. You hear it daily. I don't take any Cisco partner seriously who says these things. If they were half that good they'd work for Cisco. That they don't tells us this isn't a reasonable statement.
-
@scottalanmiller said:
@thanksajdotcom said:
I have to keep my opinions of Cisco in check because I work for one of their biggest support partners. There are people on staff here who WROTE protocols Cisco uses. Dual-CCIE level guys and above.
Every reseller claims this stuff. You hear it daily. I don't take any Cisco partner seriously who says these things. If they were half that good they'd work for Cisco. That they don't tells us this isn't a reasonable statement.
I've spoken to some of the guys here. There definitely are people here who do know their stuff.
