Install Rpm Package Openfiler. After Oracle grid infrastructure is installed and configured on both nodes in the cluster, the next step will be to install the. In this article I will be showing you step by step guide to install and configure Red Hat Cluster using. Some rpm and packages would.
Rdineshkumar.phl wrote: Thanks for the reply. Okay, i will try some other linux distro most probably ubuntu 12.04 and install kernel-server & nfs-common. I would recommend starting with the big, enterprise distributions (CentOS or OpenSuse) before playing with the lesser known and quirkier smaller distributions. I've seen a lot of people get frustrated trying to get Ubuntu to work for things that are normally pretty simple.
For experts, it is fine, but if you are in a position where you are trying to use something like OpenFiler, Ubuntu is not for you. Ubuntu is sold as being 'easy' but that is because it is focused on end user desktops, as a server it is dramatically harder to use than the normal server distributions. Scott, With respect, I think you are misguided. 'installing their product without doing enough research, getting stuck with it and then realizing that the free version has a bug introduced intentionally in the iSCSI stack so that if you don't pay for them to replace that bit of code your data will get corrupted.' We introduced a bug intentionally? Next you'll be complaining about black helicopters.
From our website: '. When you wish to deploy iSCSI as a backend for virtualization, the basic iSCSI target in Openfiler is constrained in delivery of a suitable level of performance or standards compliance. For this reason, we are now shipping the Advanced iSCSI Target Plugin. Advanced iSCSI Target Plugin is designed for production use in environments that demand very high I/O load and strict standards compliance from backend storage.' I'm sadface for you. For the record, I have said all I intend to on this topic. The floor is yours if you wish to continue your saturday night dance moves. Rafiu Fakunle Founder and Product Architect Openfiler.
Hi Dinesh, When you wish to login, please use the default credentials: username: openfiler password: password Be sure to change the password as soon as you've logged in. You should also run updates to get all latest fixes. You'll need to reboot after the updates. To run updates, 1) Login as 'root' using SSH with the password you set during the install process 2) Run the command: conary updateall 3) Run the command: conary update openfiler 4) Reboot If you run into any trouble visit the forums: or join #openfiler on irc.freenode.net Good luck! Rafiu wrote: Really?? We introduced a bug intentionally? Next you'll be complaining about black helicopters.
From our website: '. When you wish to deploy iSCSI as a backend for virtualization, the basic iSCSI target in Openfiler is constrained in delivery of a suitable level of performance or standards compliance. For this reason, we are now shipping the Advanced iSCSI Target Plugin. Advanced iSCSI Target Plugin is designed for production use in environments that demand very high I/O load and strict standards compliance from backend storage.' So you knowingly ship a version of iSCSI that doesn't work and then sell people a fix for it. Isn't that exactly what I said?
Most people who download OpenFiler don't understand any of this (if they did, they wouldn't be using a product like OpenFiler, most likely) so they are left finding out in a community like this why their virtualization platform just got corrupted. OpenFiler just isn't reliable for iSCSI. As many people here have discovered - using it grants a feeling of safety until you suddenly lose all your data from lack of full SCSI reservation support. This has been addressed in this community at length. I realize that you are new here and not necessarily aware of the years of conversations around OpenFiler here, but the talk is extensive and likely, I would say, far more extensive than on OpenFiler's forums.
Rafiu wrote: Really?? We introduced a bug intentionally? Next you'll be complaining about black helicopters. I'll rephrase then. You knowingly left in code that doesn't work so that you could sell a fix. I guess it isn't a bug if it is intentional.
But you know about the issue and you address it by selling a fix rather than fixing the issue. The result is the same, you just seem to be arguing semantics of what a bug is versus some other for of something not working (it's not a bug, it's a feature!) The bottom line is, OpenFiler isn't a good choice. As OpenFiler's architect, what benefits do you feel that OpenFiler brings to the table, especially as it is based on rPath and releases are slow in coming, compared to say CentOS? I appreciate that as the architect of the platform you have a desire to defend your product and business practices. But a bit of friendly advice, there is a ton of OpenFiler users in this community and many open questions of people needing technical assistance with OpenFiler.
Rather than defending the product on an issue that has been well established (this can't be less than the 30th time this has come up here) you should participate in the OpenFiler group and help support the people who have lost data or can't get OpenFiler to work. Right now, you are defending your business model to the very people who are attempting to provide support for your product. Routinely it doesn't work well and the solution is 'move on to something reliable'. If you have faith in your product, I expect that you would jump at the chance to support it and prove that it can outclass the competition. The floor is yours. I'll take your participation in technical solutions as your faith in what you say.
If you don't believe in OpenFiler and really are just taking advantage of people, then walk away and pretend to not see us in the community attempting to help people using it. The choice is entirely yours. We'll reference this thread in the future, a public invitation to support a product if you believe in it.
Prove to us that OpenFiler has merit. (You could, for example, use this thread to address the OP's technical issues rather than address me for agreeing that OF was the wrong choice. We were on topic and providing technical assistance to someone who needs it. It would be respectful if you, as the person in the universe best able to assist him, would do so.
If you fail to use this opportunity or find that you are unable to support OF, I think you will have proven us correct.). Dear Scott, Anyone looking to determine the merits of Openfiler can download it and try it out. It's not for everyone. I'm not defending any business model.
You'll note that I only touched upon the very serious allegation you made. If you don't want to use Openfiler, don't use it. If you don't want anyone else to use Openfiler, get a pundit gig on CNN and scream at the top of your lungs that Openfiler is the 'worstest product since the beginning of ever' and that it will eat your soul. What you're not going to get away with though is saying this: '. The free version has a bug introduced intentionally in the iSCSI stack so that if you don't pay for them to replace that bit of code your data will get corrupted' I'm probably one of the most patient people you'll ever meet, but what you've said here is unconscionable. I won't stand for it. You should apologise.
I hope you do. Rafiu Fakunle Founder and Product Architect Openfiler. Rafiu wrote: You should apologise. I hope you do. I guess that I'm lost.
I'm sorry if I am not understanding. But from your website, all technical references I have seen and even your description here. Are you not including a broken iSCSI implementation that puts data at risk and offering a paid-for fix to that? It's not like not offering the functionality at all and then offering it as an add on, the included iSCSI implementation has been causing people to lose data or, as often happens, to find out once they have invested in an OF infrastructure that they did something unsafe. You say that you won't stand for me making the accusation. And I'm happy to apologize if I am wrong.
Please correct me that your included implementation works perfectly and that the only need for the upgraded, paid for, implementation is purely performance related and not because of the missing SCSI reservations causing people to have their VMs and other data corrupt. Rafiu wrote: Anyone looking to determine the merits of Openfiler can download it and try it out. That's great and I appreciate that the product is free on its own and anyone is free to try it and use it. What we have found is that a lot of people try it and without understanding SAN in general and the SCSI reservation issue in particular implement something that works well in a lab and put it into production and are then stuck with their investment and realize that they data has been corrupted or is at risk.
Scott Alan Miller wrote: Rafiu wrote: Anyone looking to determine the merits of Openfiler can download it and try it out. That's great and I appreciate that the product is free on its own and anyone is free to try it and use it. What we have found is that a lot of people try it and without understanding SAN in general and the SCSI reservation issue in particular implement something that works well in a lab and put it into production and are then stuck with their investment and realize that they data has been corrupted or is at risk. Agreed I've run into a lot of SMB's who deployed OF for iSCSI with VMware and it bit them. At the very least in the GUI put something in that says 'DO NOT USE THIS FOR VMFS/VMWare/CLUSTERING THAT NEEDS PROPER SCSI RESRVATIONS'. That said, I'm really curious why rPath? Besides having terrible driver support, slow updates, being fairly obscure I'm trying to think of a merit to still using it.
Have you looked at SUSE Studio? Scott Alan Miller wrote: John773 wrote: That said, I'm really curious why rPath? Besides having terrible driver support, slow updates, being fairly obscure I'm trying to think of a merit to still using it. Have you looked at SUSE Studio? I was totally wanting to ask this too. I've wondered for years why obscure rPath rather than Suse Studio. We've never had access to the decision maker before.
This is pretty cool. He generally lurks on their IRC channel, but yah. I feel like there are a lot of other options (hell why not just CentOS with an added repo?). Its a really nice GUI, but if the core lacks critical drives for RAID cards and a OS that is aimed at stability and supportability, its really not that great of a choice for a NAS/SAN distro IMHO.
I can find Solaris/Redhat guys all over the place. Choosing rPath means the only means of dealing with support is going to be going through OpenFiler Supoprt is the best guess I have. Scott Alan Miller wrote: Rafiu wrote: Anyone looking to determine the merits of Openfiler can download it and try it out.
That's great and I appreciate that the product is free on its own and anyone is free to try it and use it. What we have found is that a lot of people try it and without understanding SAN in general and the SCSI reservation issue in particular implement something that works well in a lab and put it into production and are then stuck with their investment and realize that they data has been corrupted or is at risk. First, I apologise for the snide comments in my original post. I regret making them.
IET iSCSI supports RESERVE / RELEASE but not persistent reservations. AFIAK there isn't.currently. any data corruption bug in IET iSCSI. Perhaps in some corner case in a previous version of the software there may have been. I haven't come across the issue personally. The folks purchasing the plugin have done so pretty much for performance reasons or because they require PR support for clustering.
If you know of a specific way to trigger said data corruption issue with IET then let me know or post it to the IET iSCSI mailing list. Scott Alan Miller wrote: Yeah, I hate working on rPath and I'm a full time Linux guy. I'll happily support Solaris or FreeBSD before rPath Linux. Even Ubuntu would be a better choice (and that's saying a bit.) Suse would be my first choice, CentOS my second or Fedora, depending. For storage, though, you don't want to be bleeding edge (using rPath certainly solves that problem.) I don't know why rPath's conary package manager is not popular.
It's actually a very clever system - and it was invented by some of the key RPM folks to fix what they saw as inefficient in RPM. From a developer standpoint it's a massive timesaver. RPath Linux is basically just conary on top Fedora. Rafiu wrote: Scott Alan Miller wrote: Rafiu wrote: Anyone looking to determine the merits of Openfiler can download it and try it out.
That's great and I appreciate that the product is free on its own and anyone is free to try it and use it. What we have found is that a lot of people try it and without understanding SAN in general and the SCSI reservation issue in particular implement something that works well in a lab and put it into production and are then stuck with their investment and realize that they data has been corrupted or is at risk. First, I apologise for the snide comments in my original post. I regret making them.
IET iSCSI supports RESERVE / RELEASE but not persistent reservations. AFIAK there isn't.currently.
any data corruption bug in IET iSCSI. Perhaps in some corner case in a previous version of the software there may have been. I haven't come across the issue personally. The folks purchasing the plugin have done so pretty much for performance reasons or because they require PR support for clustering. If you know of a specific way to trigger said data corruption issue with IET then let me know or post it to the IET iSCSI mailing list.
Thanks, I know that jumping into a new community, especially such a huge one with so many active members is confusing and stressful, especially when it is your baby that is being discussed and, potentially, attacked. People have had a bit of issues with dropping data on OF. Maybe that was mostly 2.3, I'll try to look through the threads and get some conversations that you could hop into. Maybe there is misdiagnosis. Rafiu wrote: I don't know why rPath's conary package manager is not popular. It's actually a very clever system - and it was invented by some of the key RPM folks to fix what they saw as inefficient in RPM. From a developer standpoint it's a massive timesaver.
RPath Linux is basically just conary on top Fedora. Conary itself doesn't seem bad. I think the issue is that RPM is established and owns the market and after the Debian world pulled their marketing blitz against it, no one takes any newcomers seriously. RPM/YUM work great and seeing another package manager turns people off.
It's not a technical dislike but a market one (at the distro level.) This trickles down to end users as a lack of support and lack of releases on Conary. You can't just go out and get your favourite tools or third party apps in a Conary format and manage them along with the rest of your system. You can thank the Debian/Ubuntu hobbyist community for ruining that bit of the ecosystem for everyone. Rafiu wrote: Suse Studio is cool.
Very much so in fact. But it didn't exist when Openfiler moved from CentOS to rPath. Speaking of rPath, has everyone seen that it is gone now? They were bought by SAS and appear to have been shutdown last week. So it looks like we might not need to have this discussion anymore.
One of the concerns around rPath has always been long term support and viability. SAS didn't buy the company and keep it operating but bought 'key assets' and staff and it appears had rPath itself shut down (this is a way to transfer valuable assets while allowing non-valuable ones to not be carried onto a corporate buyer.) So rPath and the Conary support structure are probably gone for good now. Rafiu wrote: Suse Studio is cool. Very much so in fact. But it didn't exist when Openfiler moved from CentOS to rPath.
That was one of the biggest mistakes you did. Next one was licensing scst instead of going mainstream lio. Code you use was thrown away from standard linux kernel for a reason. I need things that 1) work w/o my intervention or 2) I can fix them myself easily.
Your solution falls between 1) and 2) making it VERY unattracktive for me and A LOT of other people. I'm not here to argue about your flaky business model (it's up to you what to sell and to whom and for what), lack of a back contribution to open source community whick is a shame or whatever. But if you sell a 'kit car' - make sure parts you pack to a box can be really assembled on the delivery end point:) Good luck!