|
i havent used the wiki yet, but this is the kind of knowledge that
should go into that.
I cant be the only one that always wondered what was in those sectors.
Best regards,
On Thu, Apr 12, 2012 at 9:52 PM, Jim Donoghue <jdonoghue04@xxxxxxxxx>
wrote:
> Some more interesting information:
>
> The 522-byte sector contains the 8-byte header, 512 data bytes, and 2
bytes
> at the end. The 2 bytes at the end are a LRC code (checksum), but only
one
> byte is used (the low-order one).
>
> Jim
>
>
> On Thu, Apr 12, 2012 at 6:57 PM, Jim Donoghue <jdonoghue04@xxxxxxxxx>
wrote:
>
>> Thank you. This will be extremely helpful, I just need to find some >> good
>> '6713' drives.
>>
>> Jim
>>
>>
>>
>> On Thu, Apr 12, 2012 at 5:55 PM, DrFranken <midrange@xxxxxxxxxxxx>
wrote:
>>
>>> Well you can install another drive, format it if it shows DPHnnnn
(write
>>> protected), then use the copy disk unit data - not the copy load
source.
>>>
>>> Now you can power down, swap the LS and the new drive and come back >>> up.
>>>
>>> You will however have this issue: The new LS drive is not RAID
protected
>>> because the O/S copied it's DATA not it's SECTORS. So a better option
>>> would be:
>>>
>>> Install it
>>> Format. This is a good idea even if you don't need to.
>>> Include it in RAID. If you formatted it first this will be very fast.
If
>>> not it will format it.
>>> NOW copy disk unit data.
>>> Power down
>>> Swap the drives physically.
>>> Power back up. Possibly you'll be able to exclude that drive from
RAID
>>> and if you can then you can physically pull it out. If you cannot
>>> exclude it (because it has RAID strip data on it) then it will have to
>>> stay for now.
>>>
>>> If you attempt an 'out of the box' drive duplication it will fail to
IPL
>>> because the LIC absolutely cares about serial numbers. Every drive has
a
>>> copy of the list of drives in the ASP so it knows if they have all
>>> checked in.
>>>
>>> - Larry "DrFranken" Bolhuis
>>>
>>> On 4/12/2012 5:24 PM, Jim Donoghue wrote:
>>> > Not all is lost. And, I need some help understanding how these disks
are
>>> > configured.
>>> >
>>> > First, the 'failed' load source drive. For the time being, it's not
>>> failed.
>>> > There were two bad blocks on the device, and I was lucky enough to
have
>>> a
>>> > good copy of the drive before it failed. I used the 'sg_reassign'
>>> command
>>> > (part of a Linux SCSI package) to reassign the two bad blocks. Then,
I
>>> > copied the good blocks back on the drive. Put the drive back in, and
it
>>> > IPLs.
>>> >
>>> > So, I poke around in DST. There is 1 ASP with seven drives. For some
>>> > reason, I thought there were two ASPs (one with 2 drives and the
other
>>> with
>>> > 5). The entire thing is 95% full.
>>> >
>>> > Now, I consider getting a spare drive and making it a copy of the
first
>>> > drive. The big question: if I replace the drive and it's contents >>> > are
>>> > identical, is it going to care? Or will it fail because the new
drive's
>>> > serial number isn't the same?
>>> >
>>> > Or, is there a way to add the blank drive to the system and move the
>>> load
>>> > source to it, then make it the new load source device?
>>> >
>>> >
>>> > Jim
>>> >
>>> > On Thu, Apr 12, 2012 at 2:25 PM, Jim Donoghue<jdonoghue04@xxxxxxxxx>
>>> wrote:
>>> >
>>> >> Well, that would have been a fun experiment, but it's not going to
>>> happen.
>>> >> When I got home this afternoon, tried to IPL the system and get a
SRC
>>> >> 27419000. It turns out the other half of what used to be the load
>>> source
>>> >> mirror is now bad. The drive in the first slot has an unrecoverable
>>> read
>>> >> error, and the one in the second slot has a recoverable read error.
(I
>>> >> determined this by attempting to read them using SCSI tools on the
PC).
>>> >>
>>> >> Perhaps I should have left it at the scrap metal place.
>>> >>
>>> >> Jim
>>> >>
>>> >>
>>> >> On Thu, Apr 12, 2012 at 12:16 PM, Jim Donoghue<
jdonoghue04@xxxxxxxxx
>>> >wrote:
>>> >>
>>> >>> It may not matter about the password after all. I can log in as
>>> >>> '22222222', but as I mentioned eariler, the function I need is
>>> restricted.
>>> >>> There is a record for each DST user ID that contains a list of
>>> functions
>>> >>> that the user is allowed access to. I may be able to make the
>>> '22222222'
>>> >>> user's entry have the function I need. I found some interesting
areas
>>> on
>>> >>> the disk during lunch, an audit log and the list of DST user
profiles:
>>> >>> 'SecServiceUserProfile' and 'SecPrivilegeList'. Interesting stuff.
>>> >>>
>>> >>> Jim
>>> >>>
>>> >>>
>>> >>>
>>> >>> 2012/4/12 Roberto José Etcheverry Romero<
yggdrasil.raiker@xxxxxxxxx>
>>> >>>
>>> >>>> What both of you mean, is. There is usually no way to derive the
>>> >>>> password from whatever the OS stores, in linux's case its a >>> >>>> shadow
>>> >>>> file aka mathematical hash of the password.
>>> >>>> I would just pop a lic cd and install, but it is technically a
breach
>>> >>>> of the os licence. And i believe it's next to impossible to buy a
key
>>> >>>> for such an old system.
>>> >>>>
>>> >>>> Best regards,
>>> >>>>
>>> >>>> PD: you are better off buying a 520 off ebay with the os key, i
have
>>> >>>> one, no client access and the such, but it does work.
>>> >>>>
>>> >>>>
>>> >>>> On Thu, Apr 12, 2012 at 12:03 PM, DrFranken<midrange@xxxxxxxxxxxx
>
>>> >>>> wrote:
>>> >>>>> I disagree, they are certainly stored. Were they not stored you
>>> could
>>> >>>>> not log in. And they must be on disk because I can pull a set >>> >>>>> of
>>> >>>> drives
>>> >>>>> lock them into another machine, fire them up and sign on. Just
did
>>> >>>> that
>>> >>>>> this week with a set of drives from last year's COMMON
conference.
>>> >>>>>
>>> >>>>> Now stored in clear text, of course not. They are encrypted (one
way
>>> >>>>> only) and then stored, but they or at least a representation of
them
>>> >>>> are
>>> >>>>> in there.>
>>> >>>>> - Larry "DrFranken" Bolhuis
>>> >>>>>
>>> >>>>> On 4/12/2012 10:44 AM, Mark S. Waterbury wrote:
>>> >>>>>> Jim:
>>> >>>>>>
>>> >>>>>> Passwords are never stored permanently (on disk) in OS/400 or
IBM i
>>> >>>> (or
>>> >>>>>> in most any other modern operating systems).
>>> >>>>>>
>>> >>>>>> Instead of using "22222222", try using "QSECOFR" as the DST
userID.
>>> >>>>>>
>>> >>>>>> Cheers,
>>> >>>>>>
>>> >>>>>> Mark S. Waterbury
>>> >>>>>>
>>> >>>>>> > On 4/12/2012 9:49 AM, Jim Donoghue wrote:
>>> >>>>>>> The machine was 'rescued' from the scrap metal place. I can
log in
>>> >>>> to DST
>>> >>>>>>> with 22222222, but can't access the option necessary to change
the
>>> >>>> QSECOFR
>>> >>>>>>> password. I think this machine has V4R3 on it.
>>> >>>>>>>
>>> >>>>>>> I think I am going to have to write some tools to hack around
with
>>> >>>> an image
>>> >>>>>>> file from the load source disk. I have a hex editor I wrote
that
>>> will
>>> >>>>>>> display the EBCDIC characters. What I am thinking of doing is
>>> >>>> grabbing two
>>> >>>>>>> images of the disk - one as-is, and a second one after I >>> >>>>>>> change
>>> the
>>> >>>>>>> password for the DST user 22222222. Then maybe I can find >>> >>>>>>> where
>>> the
>>> >>>>>>> passwords are stored.
>>> >>>>>>>
>>> >>>>>>> Jim
>>> >>>>>>>
>>> >>>>>>> On Thu, Apr 12, 2012 at 8:42 AM, Jerry C. Adams<
midrange@xxxxxxxx
>>> >
>>> >>>> wrote:
>>> >>>>>>>> I'm guessing that the QSECOFR password wasn't included either
>>> when
>>> >>>> he
>>> >>>>>>>> bought
>>> >>>>>>>> the machine. A company that I worked for years ago had the
same
>>> >>>> problem:
>>> >>>>>>>> No
>>> >>>>>>>> QSECOFR password. But we booted the system into DST and used
>>> >>>> either the
>>> >>>>>>>> 22222222 or 11111111 profile to change the password for
QSECOFR.
>>> >>>> That was,
>>> >>>>>>>> if I remember correctly, a V3 something machine.
>>> >>>>>>>>
>>> >>>>>>>> Jerry C. Adams
>>> >>>>>>>> IBM i Programmer/Analyst
>>> >>>>>>>> Sir, you have tasted two whole worms; you have hissed all my
>>> mystery
>>> >>>>>>>> lectures and been caught fighting a liar in the quad, you >>> >>>>>>>> will
>>> >>>> leave Oxford
>>> >>>>>>>> by the next town drain. - Rev. William Spooner
>>> >>>>>>>> --
>>> >>>>>>>> A&K Wholesale
>>> >>>>>>>> Murfreesboro, TN
>>> >>>>>>>> 615-867-5070
>>> >>>>>>>>
>>> >>>>>>>> -----Original Message-----
>>> >>>>>>>> From: midrange-l-bounces@xxxxxxxxxxxx
>>> >>>>>>>> [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jim
>>> >>>> Oberholtzer
>>> >>>>>>>> Sent: Thursday, April 12, 2012 8:18 AM
>>> >>>>>>>> To: Midrange Systems Technical Discussion
>>> >>>>>>>> Subject: Re: Load source on old 9406-720
>>> >>>>>>>>
>>> >>>>>>>> Your chances of finding the DST password are about the same >>> >>>>>>>> as
>>> that
>>> >>>> of a
>>> >>>>>>>> snowball inside a blast furnace, not gonna happen.
>>> >>>>>>>>
>>> >>>>>>>> Use Larry's suggestion and from the console, signed on as
>>> QSECOFR,
>>> >>>> issue
>>> >>>>>>>> the
>>> >>>>>>>> CHGDSTPWD *DEFAULT command.
>>> >>>>>>>>
>>> >>>>>>>> Jim Oberholtzer
>>> >>>>>>>> Chief Technical Architect
>>> >>>>>>>> Agile Technology Architects
>>> >>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>> On 4/12/2012 7:31 AM, Roberto José Etcheverry Romero wrote:
>>> >>>>>>>>> If you have 22222222 access you could SEE which disk is the
>>> >>>>>>>>> loadsource, just go to the rackconfig and it will be marked
>>> with *
>>> >>>>>>>>>> From there, take the serial number and just take each
>>> disk.
>>> >>>>>>>>> To aid in your hacking, stop all parity protection (one less
>>> >>>> abstraction
>>> >>>>>>>> layer).
>>> >>>>>>>>> And good luck i doubt the users/pass are stored in >>> >>>>>>>>> plaintext.
>>> >>>>>>>>> You could also dump an op21 and look at the lic code part...
>>> >>>>>>>>>
>>> >>>>>>>>> Keep us posted, i'm curious about this.
>>> >>>>>>>>>
>>> >>>>>>>>> best regards,
>>> >>>>>>>>>
>>> >>>>>>>>> Roberto
>>> >>>>>>>>>
>>> >>>>>>>>> On Thu, Apr 12, 2012 at 8:12 AM, DrFranken<
>>> midrange@xxxxxxxxxxxx>
>>> >>>>>>>> wrote:
>>> >>>>>>>>>>> Well I can tell you it's the top cage, left disk unit,
>>> ALMOST
>>> >>>>>>>> certainly.
>>> >>>>>>>>>>> It's possible that it's the 2nd disk from the left.
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> Now on this quest to find the DST Password with a disk
>>> >>>>>>>>>>> editor...... Yeah good luck with that.
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> I believe they are encrypted, and worse in EBCDIC so
>>> noodling
>>> >>>> for
>>> >>>>>>>>>>> recognizable stuff will be hard.
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> Why don't you run CHGDSTPWD and reset the QSECOFR DST
>>> profile
>>> >>>> that
>>> >>>>>>>> way?
>>> >>>>>>>>>>> - Larry "DrFranken" Bolhuis
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> On 4/12/2012 6:44 AM, Jim Donoghue wrote:
>>> >>>>>>>>>>>>> I have this old 9406-720. It has five drives in the
>>> cage on
>>> >>>> the
>>> >>>>>>>>>>>>> top left side (below the control panel), and two in the
>>> cage
>>> >>>>>>>>>>>>> below it. How do I find out which is the load source? I
can
>>> >>>> only
>>> >>>>>>>> access DST with the '22222222'
>>> >>>>>>>>>>>>> user ID. I need to find the load source device so I
can
>>> poke
>>> >>>>>>>>>>>>> into it with a disk editor and hopefully find where the
DST
>>> >>>>>>>> passwords are stored.
>>> >>>>>>>>>>>>> Thanks,
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>> Jim
>>> >>>>>>>>>>> --
>>> >>>>>>>> --
>>> >>>>>>>> This is the Midrange Systems Technical Discussion >>> >>>>>>>> (MIDRANGE-L)
>>> >>>> mailing list
>>> >>>>>>>> To post a message email: MIDRANGE-L@xxxxxxxxxxxx To
subscribe,
>>> >>>>>>>> unsubscribe,
>>> >>>>>>>> or change list options,
>>> >>>>>>>> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
>>> >>>>>>>> or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting,
please
>>> >>>> take a
>>> >>>>>>>> moment to review the archives at
>>> >>>> http://archive.midrange.com/midrange-l.
>>> >>>>>>>> --
>>> >>>>>>>> This is the Midrange Systems Technical Discussion >>> >>>>>>>> (MIDRANGE-L)
>>> >>>> mailing list
>>> >>>>>>>> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
>>> >>>>>>>> To subscribe, unsubscribe, or change list options,
>>> >>>>>>>> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
>>> >>>>>>>> or email: MIDRANGE-L-request@xxxxxxxxxxxx
>>> >>>>>>>> Before posting, please take a moment to review the archives
>>> >>>>>>>> at http://archive.midrange.com/midrange-l.
>>> >>>>>>>>
>>> >>>>>>>>
>>> >>>>> --
>>> >>>>> This is the Midrange Systems Technical Discussion (MIDRANGE-L)
>>> mailing
>>> >>>> list
>>> >>>>> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
>>> >>>>> To subscribe, unsubscribe, or change list options,
>>> >>>>> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
>>> >>>>> or email: MIDRANGE-L-request@xxxxxxxxxxxx
>>> >>>>> Before posting, please take a moment to review the archives
>>> >>>>> at http://archive.midrange.com/midrange-l.
>>> >>>>>
>>> >>>> --
>>> >>>> This is the Midrange Systems Technical Discussion (MIDRANGE-L)
>>> mailing
>>> >>>> list
>>> >>>> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
>>> >>>> To subscribe, unsubscribe, or change list options,
>>> >>>> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
>>> >>>> or email: MIDRANGE-L-request@xxxxxxxxxxxx
>>> >>>> Before posting, please take a moment to review the archives
>>> >>>> at http://archive.midrange.com/midrange-l.
>>> >>>>
>>> >>>>
>>> --
>>> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
>>> list
>>> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
>>> To subscribe, unsubscribe, or change list options,
>>> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
>>> or email: MIDRANGE-L-request@xxxxxxxxxxxx
>>> Before posting, please take a moment to review the archives
>>> at http://archive.midrange.com/midrange-l.
>>>
>>>
>>
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
