Raid on a raid issue

Doll, Margaret Ann margaret_doll at brown.edu
Thu Jul 24 20:06:37 UTC 2014


There are a lot of entries in /var/log/messages noting an abort of rask.

Unfortunately the system and the "new" raid have the same name.


On Thu, Jul 24, 2014 at 4:02 PM, Jamie Fargen <jfargen at gmail.com> wrote:

> It doesn't sound like they are in a cluster or hpc environment where you
> could use xming+putty/xrdp/FreeNX.
>
> Sounds like the professors just buy workstations for their simulations,
> which is very, very inefficient way to utilize resources.
>
> Is there anything in the logs that can give us an idea of the with errors
> you are facing?
> On Jul 24, 2014 3:54 PM, <m.roth at 5-cent.us> wrote:
>
> > Doll, Margaret Ann wrote:
> > > Also, some of the software that we run is only written for the unix
> > > platform, ie. a program like gaussian.
> > >
> > For Windows users, are you familiar with putty, which is freeware? That's
> > what our people use here.
> >
> >       mark
> > >
> > > On Thu, Jul 24, 2014 at 3:36 PM, Doll, Margaret Ann
> > > <margaret_doll at brown.edu
> > >> wrote:
> > >
> > >> My primary function is to service unix computers within two
> departments.
> > >>
> > >> The unix computers are often used by groups of students running large
> > >> programs or analyzing extremely large data sets.
> > >>
> > >> Samba allows Window users ( and Macs) to mount the data on the unix
> > >> servers on their computers for analysis.
> > >>
> > >>
> > >> On Thu, Jul 24, 2014 at 2:59 PM, <m.roth at 5-cent.us> wrote:
> > >>
> > >>> Doll, Margaret Ann wrote:
> > >>> > Sometimes the su user is the owner.
> > >>> >
> > >>> Um... so, why are you administering his box, and why is it serving
> > >>> samba
> > >>> across campus? That raises my serious security hackles....
> > >>>
> > >>>          mark
> > >>> >
> > >>> > On Thu, Jul 24, 2014 at 2:51 PM, <m.roth at 5-cent.us> wrote:
> > >>> >
> > >>> >> Doll, Margaret Ann wrote:
> > >>> >> > I created a system with three raids using the DELL configuration
> > >>> tools
> > >>> >> > prior to installation of the RedHat system, 6.5.  The system
> raid
> > >>> was
> > >>> >> > divided up into numerous partitions for the system and four
> large
> > >>> >> > partitions for users.  This system raid was a raid 0.
> > >>> >> >
> > >>> >> > After the installation samba worked.  I could log into the
> system
> > >>> from
> > >>> >> > another subnet.
> > >>> >> >
> > >>> >> > Then a user with su privileges, took the four large partitions
> on
> > >>> the
> > >>> >> > system raid and made them into another raid using mdadm --create
> > >>> and
> > >>> >> > mdadm--assemble.
> > >>> >> >
> > >>> >> > Now the ssh connections from across the subnets time out.  Samba
> > >>> fails
> > >>> >> > with "NT_STATUS_ACCESS_DENIED."  I can't even ping the system
> from
> > >>> >> across
> > >>> >> > campus.
> > >>> >> >
> > >>> >> > I have had to modify /etc/fstab so that the four original
> > >>> partitions
> > >>> >> do
> > >>> >> no
> > >>> >> > try to mount.  The raid composed of the four partitions mounts
> as
> > >>> >> > /dev/md127p1.
> > >>> >> >
> > >>> >> > Is the ssh timeout problem, ping problem and samba problem all
> > >>> caused
> > >>> >> by
> > >>> >> > the raid on raid creation?  The timing of the creation of the
> new
> > >>> raid
> > >>> >> > indicates that it is.
> > >>> >> >
> > >>> >> First of all, I'd take su away from the user, who doesn't know
> what
> > >>> >> they're doing.
> > >>> >>
> > >>> >> Next - and I'm *really* not strong on samba - I'd assume that the
> > >>> system
> > >>> >> itself hasn't been reconfigured to (whatever word is used for a
> > >>> samba
> > >>> >> export). The ID's changed, the UUID's changed, etc, etc. And, of
> > >>> course
> > >>> >> any metadata on them is toast. I'm afraid you're going to have to
> > >>> >> recreate
> > >>> >> them from scratch; anything on them... hope you've got backups.
> > >>> >>
> > >>> >>         mark
> > >>> >>
> > >>> >> --
> > >>> >> redhat-list mailing list
> > >>> >> unsubscribe
> > >>> mailto:redhat-list-request at redhat.com?subject=unsubscribe
> > >>> >> https://www.redhat.com/mailman/listinfo/redhat-list
> > >>> >>
> > >>> > --
> > >>> > redhat-list mailing list
> > >>> > unsubscribe mailto:redhat-list-request at redhat.com
> > ?subject=unsubscribe
> > >>> > https://www.redhat.com/mailman/listinfo/redhat-list
> > >>> >
> > >>>
> > >>>
> > >>> --
> > >>> redhat-list mailing list
> > >>> unsubscribe mailto:redhat-list-request at redhat.com
> ?subject=unsubscribe
> > >>> https://www.redhat.com/mailman/listinfo/redhat-list
> > >>>
> > >>
> > >>
> > > --
> > > redhat-list mailing list
> > > unsubscribe mailto:redhat-list-request at redhat.com?subject=unsubscribe
> > > https://www.redhat.com/mailman/listinfo/redhat-list
> > >
> >
> >
> > --
> > redhat-list mailing list
> > unsubscribe mailto:redhat-list-request at redhat.com?subject=unsubscribe
> > https://www.redhat.com/mailman/listinfo/redhat-list
> >
> --
> redhat-list mailing list
> unsubscribe mailto:redhat-list-request at redhat.com?subject=unsubscribe
> https://www.redhat.com/mailman/listinfo/redhat-list
>



More information about the redhat-list mailing list