phat-devel — For people who are (or plan to be) active in the development of PHAT.

[PHAT-devel] finally, some test code.

[Brian K. J. <jonesy@CS.Princeton.EDU>]

Hi all.

I've been pounding away at the phatAPI.php file which is on the CVS
server.  At this point, the only really meaningful files to anyone
except for me are:

phatAPI.php
portscan.php
regression.php
testconf.php

The regression.php file is some of the test code I've been using.  I
just threw some of it into this file, wrapped some functions around it,
and made a little form that will let you run them one at a time.  It
takes its info from testconf.php.  If you write other code, please also
write a piece of code in a function in regression.php for reference and
testing.  It'll help everyone. 

Also, lots of updated status and other info can be seen in the newly
added TODO file, the README, and, of course, the API file.

If you're STILL wanting more info, there's a file called
'funclist.status'.  I grep'ed through the whole code tree for the word
'function' and labeled each function as either PORTED or UNTOUCHED or
whatever.  A good bit of functionality has been ported at this point. 
Enough to at least be able to get an idea as to general direction.  Code
cleanups, ideas, corrections, etc are welcome.

Later.
brian.
-- 

Brian K. Jones
System Administrator
Dept. of Computer Science, Princeton University
jo...@cs...
http://www.linuxlaboratory.org
http://phat.sourceforge.net
Voice: (609) 258-6080

[PHAT-devel] what's happening with PHAT.

[Brian K. J. <jonesy@CS.Princeton.EDU>]

Hi all.

I've actually been somewhat active on the CVS server, believe it or
not.  I understand that the code anyone has is almost worthless, so
progress is being inspired mostly by my desire to produce code that
works to some degree.  

I'm starting with the beginnings of an API.  The API, so far, is
object-oriented, because it seems the best way to provide really easy
access to a very large amount of data and very large numbers of
functions, many of which make network calls or other expensive calls. 
This new API in the works is on the CVS server and is called
phatAPI.php.  Right now it's all one file.

Currently, there are only two classes in there, and a TON of comments. 
The classes are 'Port' and 'Inspector'.  

'Port' is essentially an SNMP abstraction layer that will eventually
support everything you can possibly want to do with a port (using both
'snmpget' and 'snmpset').  Right now, most of the stuff there is 'get'
related, because it's easier for me to test the code for that without
hurting anyone. :)

'Inspector' is probably going to be broken into two classes.  One called
'Node' that will provide information about a nameless, faceless
networked device, and the Inspector class will stay in place to provide
functionality like the 'rup' method, which will eventually look
something like Sun's 'rup' command.  The point is that it will provide
more high-level network data, and Node will provide system level snmp
information, and then Port will provide Port level data.  

All of my work is revolving around adding functions to the api, and
testing the stuff that's there.  I haven't really touched any of the
presentation stuff.  Once the functionality is there, I can put together
basic presentation somewhat quickly - enough to interest someone else
who knows more about it, hopefully. ;)

I'm also not doing much with the database yet.  I figure we have to be
able to *get* the data before we can put it in the database.  Also, I'm
hoping when database time comes, we'll be able to integrate either the
PEAR or ADODB abstraction layers.

Later this week I'll provide my test code so that everyone who has some
kind of basic network can see what the api does and that it works.  I
also hope it'll spawn s'more thought and ideas.

cheers.
brian.  
-- 

Brian K. Jones
System Administrator
Dept. of Computer Science, Princeton University
http://www.linuxlaboratory.org
jo...@cs...
Voice: (609) 258-6080

[PHAT-devel] API, and portscanner begun.

[Brian K. J. <jonesy@CS.Princeton.EDU>]

Hi,

Today I've committed a couple of new files to the CVS server.  One is a
portscanner.  It's fairly simple right now - but it pretty much works if
you know its limitations (read the code comments), and it's not
dependent on anything.  It'll work anywhere.

I've also started on a proper API for PHAT.  I'm only currently
addressing the networking/SNMP portions of everything now, and by the
time all of that is working, we may possibly have a more clear direction
on the database-related stuff (like what to put in the database, etc). 
Certainly, for now, it's not going to hurt to keep the data 'live' until
we figure that out. I'm also not going into much detail on presentation.

Anyone still interested in PHAT development should definitely read the
phatAPI.php file's comments.

Later.
-- 

Brian K. Jones
System Administrator
Dept. of Computer Science, Princeton University
http://www.linuxlaboratory.org
jo...@cs...
Voice: (609) 258-6080

[PHAT-devel] PHAT 0.0.1 ("pseudocode") released

[Brian K. J. <jonesy@CS.Princeton.EDU>]

Hi all,

Just wanted to let everyone know that, while I've been doing TONS and
tons of 'scribbling' with new ideas about how to make PHAT into
something wonderful, very little new code has been written in some
time.  Recently, I've found myself in this vicious cycle of 
A) Not wanting to release what is, essentially, pseudocode, and
B) Not having a lot of time to devote to cleaning it up and
expanding/fixing it, which is, of course, fixed by releasing it (see
item A).  

So the source has been posted.

I know there are tons of issues with the code as it is now.  I know the
design is very simplistic, sometimes redundant, sometimes nonsensical...
so save your emails about that.  The code was released more to act as a
platform for ideas on what direction we should head in, and to get more
eyes and fingers on the code.

So have at it!  And lets keep correspondence to the list so I don't have
to visit the sourceforge forums every day :-)

/njcajun

-- 

Brian K. Jones
System Administrator
Dept. of Computer Science, Princeton University
http://www.linuxlaboratory.org
jo...@cs...
Voice: (609) 258-6080

[PHAT-devel] Re: phat

[Brian K. J. <jonesy@CS.Princeton.EDU>]

On Thursday 25 April 2002 05:34 pm, you wrote:
> How are you doing?
>
> I have access to three different cisco devices, a number of
> printers, netware, and win2k..
>
> can contribute printer / win2x OIDs/modules
>

Awesome - that'll save me from having to mess with windows and=20
printers -- my two arch enemies in the computing world :)

> Coding style is very important. It should be defined early for
> multi-member projects.
> I'm sure my style differs from yours.
>
> Below is a snippet of code from my current project
>
> <snip>
> /**
> * Function displayLinks
> * Provide the menu system links for page.
> * @param array $link_array
> * @return string
> */
>
> function displayLinks($link_array)
> {
>     reset($link_array);
>
>     while (list($key, $val) =3D each($link_array)) {
>        $label =3D ucfirst($key);
>
>    echo "";
>           echo "<FONT SIZE=3D'1' FACE=3D'Arial'>";
>    // see if we want to open in a new window
>    // code added 09-24-2001
>     if(ereg("rhttp://", $val)) {
>            $val =3D ereg_replace("rhttp", "http", $val);
>            echo "<A HREF=3D\"$val\"
> TARGET=3D\"_blank\">$label</A></FONT>\n";
>
>           } else {
>       echo " <A HREF=3D\"$val\">$label</A></FONT>\n";
>    }
>
>     }
>
> } // end of function
> </snip>

Actually, our coding style doesn't differ all that much.  I use camel=20
notation for my function names, as do you, I'm a stickler about using=20
newlines in my generated html, and I tend to comment the hell out of=20
everything.  The one main difference I see right away is that I put=20
all of my curly braces on the left -- never at the end of a line, so=20
where you write:
=09'if(ereg("rhttp://", $val)){'
I would write
=09'if(ereg("rhttp://", $val))
=09{'
I just find it easier to debug scope problems that way.  Instead of=20
looking for keywords that would necessitate a brace, I can just=20
scroll down the left side and look for the brace itself.  However,=20
this causes a bunch of extra lines in the code, so when everything is=20
done and ready to go, a lot of times I find myself moving the braces=20
to look like your code.  I guess this could be annoying if I forgot=20
to do it, but I've never heard complaints from others about it.

The other thing I noticed is that you used 'while(list() each())',=20
where I use 'foreach()'.  This quite likely is an indicator that=20
you've been coding PHP longer than me, as foreach wasn't available=20
until later versions of PHP.  One of the benefits of open source=20
projects is that, in this case, I can probably pick up some of your=20
good coding style habits, and maybe I'll bring something to light on=20
the networking side or a newer PHP function you like.  It's an=20
iterative process that benefits everyone that way. =20

As for Steve ('elgersma') and tengi, they'd have to respond to this=20
for themselves, but I don't think this will be a major debate.  I've=20
actually only ever seen tengi write code in shell (csh no less!) and=20
perl.  Steve's been coding PHP for so long I'm convinced he proofread=20
Rasmus's prototypes. :)

>
> At work my boss's and I maintain the internal Web env. his styles
> differs from mine as a result we
> defined some basic rules that make sure the code supports the
> interface and layout.

Maybe we can work from that as a springboard for ideas?  I haven't=20
ever worked on a project that had a coding standard.  I worked on=20
PostNuke, but there is NO coding standard there at all.  The code is=20
very hard to maintain as a result.  I'm a fan of coding standards, I=20
was just never in a position to implement one.=20
>
> rules for modules that get included in the releases or made
> available externally, must avoid breaking
> defined interface/layout.

This is a given.  Nothing will be released unless it plays nice with=20
everything else.  If it's truly mindblowing, maybe it constitutes a=20
little extra work on our part to integrate it, but...
>
> this also prevents problems when someone leaves the project and
> someone else has to support his/her code..
>
> Of the 25 questions raised by PHAT, which are answered? could you
> provide a marker? (Thanks)

PHAT, in its current state, can graphically show a list of switches,=20
and allows users to enter new switches as well.  In this list,=20
clicking on a switch name will bring you to a framed window that=20
shows a graphical representation of all of the switch's ports (green=20
are up, blue are down).  Hovering over a port shows the port name and=20
its status (this is arbitrary, it can show you almost anything in the=20
interfaces branch by changing which variable is placed inside the=20
<acronym> tag used to enable this feature).  The right pane lists all=20
of the vlans defined on the switch, including which ports are members=20
of each vlan.  On the left, there's also a list of vlans, but they=20
are just links.  Clicking on one of the links grays out the ports in=20
the graphic that are not members of the vlan.  Clicking on an actual=20
port will update the right pane and show a list of clients that have=20
been seen passing traffic across this port - their mac, ip and=20
hostname.  Clicking a hostname will show you a table of the snmp=20
details of that host, and also will port scan a fixed range (for now)=20
of ports and tell you what's open on that host.
>
> Suggested naming convention for sysOID files.'3com3300.inc.php'.
That's exactly how I've been naming things so far.

> does the file just define the OIDs or does it include functions to
> process them also?

The bottom line for these files, as I see it, is that they're included=20
so they can simply provide values for variables that are referenced=20
in the file that includes it.  A lot of the processing is static and=20
can be in a completely separate file, to the extent that the data=20
looks the same coming back.  If processing needs to be done that is=20
specific to a model, this 'inc.php' file seems the most logical place=20
to put it right now.

>
> How many scripts is the current code base?

Currently there are 11 scripts.  There are more that I'm working on in=20
an effort to try and separate the logic from the presentation. =20
Unfortunately, this is an area I'm not quite so slick at.  I'll=20
likely need Steve ('elgersma') to help me out with that in his=20
spurious free time (NOT).  He has more experience in most areas of=20
PHP :)  If you have ideas, check out the existing code (I'll be=20
sending it along shortly) and let me know.

I'm not putting the code into CVS just yet for two main reasons:
1.  I'm still learning CVS at this point, and I'm not very good at it. =20
It still seems overly convoluted to me, but I'm working on it.

2.  The code has a couple of dependencies that warrant keeping it in=20
the closet for now.  One is that right now it's dependent on NIS to=20
translate a MAC to an IP address (this is a major showstopper).  The=20
other is MySQL.  The current code works with MySQL, but I'm in the=20
process of designing a PostgreSQL database for it, so I don't want a=20
bunch of developers to start working on the code and then be=20
completely disoriented when it moves to PG.

> .
> later
Later.
>
> CT
>
--=20

Brian K. Jones
System Administrator
Dept. of Computer Science, Princeton University
jo...@cs...
Voice: (609) 258-6080

[PHAT-devel] Re: phat

[Chauncey T. <ct...@wt...>]

How are you doing?

I have access to three different cisco devices, a number of printers,
netware, and win2k..

can contribute printer / win2x OIDs/modules

Coding style is very important. It should be defined early for
multi-member projects.
I'm sure my style differs from yours.

Below is a snippet of code from my current project

<snip>
/**
* Function displayLinks
* Provide the menu system links for page.
* @param array $link_array
* @return string
*/

function displayLinks($link_array)
{
    reset($link_array);

    while (list($key, $val) = each($link_array)) {
       $label = ucfirst($key);

   echo "";
          echo "<FONT SIZE='1' FACE='Arial'>";
   // see if we want to open in a new window
   // code added 09-24-2001
    if(ereg("rhttp://", $val)) {
           $val = ereg_replace("rhttp", "http", $val);
           echo "<A HREF=\"$val\" TARGET=\"_blank\">$label</A></FONT>\n";

          } else {
      echo " <A HREF=\"$val\">$label</A></FONT>\n";
   }

    }

} // end of function
</snip>

At work my boss's and I maintain the internal Web env. his styles differs
from mine as a result we
defined some basic rules that make sure the code supports the interface
and layout.

rules for modules that get included in the releases or made available
externally, must avoid breaking
defined interface/layout.

this also prevents problems when someone leaves the project and someone
else has to support his/her code..

Of the 25 questions raised by PHAT, which are answered? could you provide
a marker? (Thanks)

Suggested naming convention for sysOID files.'3com3300.inc.php'. does the
file just define the OIDs or does it include functions to process them
also?

How many scripts is the current code base?
.
later

CT

"Brian K. Jones" wrote:

> On Wednesday 24 April 2002 07:17 pm, you wrote:
> > How are you doing?
>
> Good.  I was sick yesterday - so I'm better :)
>
> > Cool... I'm looking forward to seeing what you have...
> > I have a collection of OIDs... will look for them.
>
> Great.  By the way, If you go to sourceforge.net/projects/phat, you'll
> notice that yesterday I posted a very informal overview and design
> spec, and also posted a help wanted for another analyst/designer.  I
> figure we have the development parts pretty much down now, and there
> aren't many developers with the vision to start pretty much from
> scratch like we're doing anyway.  More developers will probably join
> once there's some code to play with.
>
> >
> > When you say modules for every sysOID. Do you mean creating include
> > files that contain oids for a particular device..
>
> That's exactly right, but only where it's absolutely necessary.  The
> standard stuff is easy, since, for example, everything has a 'system'
> branch :)
> >
> > e.g.
> > sysOID_common.oids - OIDs that will extract from any device
> > sysOID_netware.oids - contains netware stuff...
> > sysOID_cisco_1600c.oids - contains
> > sysOID_apache.oids
>
> The naming convention can, I guess, be pretty intuitive to the end
> user.  If necessary, we can have the program grab a sysOID live and
> have it look for the actual file name that corresponds to the ID in a
> lookup table.  So we can actually say, for a 3Com 3300:
> '3com3300.inc.php'.  Then, when the program finds a sysOID of
> 43.22.1.14, it can look it up in the database and it'll match up with
> the file name.  The part that became a little tricky was that I
> realized that '43' is just a vendor's enterprise mib branch
> assignment.  You get to the model using the numbers that come after
> that.
>
> >
> > This way I can submit the proprietary vendor OIDs for the devices I
> > have access to.
>
> That would be awesome.  Are these devices you have access to?  I can
> write up the modules and everything, but there may be some things I
> don't have available to me to test against.
>
> >
> > Are you wanting to focus on network devices (Routers, switchers...)
> > only or include support
> > for any type of network device?.
>
> Well, I think supporting anything with a network connection is a good
> goal, and that's what we're going for in my eyes.  I'm starting with
> switches and routers because those are by far the hardest, since
> every technology on a network has to be supported, or at least not
> hindered by, these devices.  Probably while we're working on those,
> we'll take a break from the madness and write modules for things like
> the ucd or sun agents that typically live on hosts, try to work with
> the application specific agents like the one for apache, etc.  As
> developers join, they'll certainly have their favorite toys to play
> with...  The job is slightly larger for whoever wants to do stuff
> that isn't a switch right away -- there's no interface or anything --
> so they'll need to do some design work as well :)
>
> >
> > What type of data are you planning on storing in the db?
> > Will I be able to search for a device by name and make changes/view
> > that device data?
>
> Yep.  The challenge here is that it's tough to know what things a user
> will want to change.  The database is there to improve the
> performance, and in some cases, aggregate data that would otherwise
> take a week to grab live, and then aggregate all in the code (and who
> wants to write that code anyway).  It'll mostly hold data that's
> considered relatively static -- how often does the ifMTU change for a
> given interface?  Likely never, unless you have a very old device
> that you're planning to run multicast over or something :)
> >
> > Oh... Have you defined the required coding style?
>
> Not really.  What are YOUR thoughts on this?  The code that actually
> is working now is kind of crude and simple.  It gets the job done,
> but it's not the prettiest code in the world, because once I got one
> feature working, I immediately moved on to the next.  I'm a stickler
> for 'clean code'.  I'd like to keep presentation and logic as
> separate as possible, and have recently been reading about a couple
> of new ways to do this.  However, I don't want the code to become
> completely non-intuitive to other developers or myself in the
> process.  Advisory comments and suggestions are more than welcome, as
> they are for every other aspect of the project - as always.
>
> I've said a lot here, but there's even more stuff in the design spec.
> You really should read it - it'll probably give you more questions to
> ask or ideas, which would be helpful.  If you have 'critical
> questions' to add to the list of questions that PHAT tries to solve,
> let us all know.  One question I didn't address was 'when will there
> be code to look at'?  Well, read the design spec and you'll see what
> the major holdup is.  It's a pain in the butt now, but will make the
> overall tool much more flexible, and the code will be even easier to
> write.
> >
> > Later..
> > CT
> Later,
> /brian
> >
> > jonesy@CS.Princeton.EDU wrote:
> > > I've done some of the layout, but most of it is just sort of a
> > > breeding ground for ideas, not really what I would consider a
> > > prototype look for a finished product.  I would say, though, that
> > > it seems to be shaping up to look more like an application and
> > > less like a website. I'll post some screenshots.
> > >
> > > I'd like your input on some of the behind-the-scenes code
> > > organization, as some things have been troubling me.  Let me
> > > update you on where I'm at now.
> > >
> > > I'm actually in the middle of doing almost nothing but
> > > data-finding and database design (again).  I decided to switch
> > > from using MySQL to PostgreSQL, because I'd really like to take
> > > advantage of things like views, foreign keys, and the
> > > network-specific datatypes.
> > >
> > > At the same time, I'm also doing some interface 'sketching' in an
> > > effort to flesh out as much of the app in my head and on paper as
> > > I can before we get started on coding what will be the finished
> > > product.
> > >
> > > One challenge is going to be writing modules for every sysOID.
> > > Every vendor implements different standard mibs (though some are
> > > consistent), and a lot of the REALLY cool information is locked
> > > up in proprietary vendor mibs.  All of these mibs contain similar
> > > information, but it's a matter of getting it out no matter what
> > > make and model it is.
> > >
> > > I'm at home today, but after this weekend I'll put up the code to
> > > SF so you can grab it and see the sort of structure it's starting
> > > to take.  I can also post some screen shots in the event that you
> > > don't have any devices to run this against and get meaningful
> > > data.
> > >
> > > Later.
> > >
> > > Quoting Chauncey Thorn <ct...@wt...>:
> > > > How are you doing?
> > > >
> > > > Glad to hear from you.
> > > > I've worked for a company that raised a similar topic. Not much
> > > > you can
> > > > do if you're coding
> > > > on their clock, using their editor running on whatever OS.
> > > >
> > > > Most Network/Account policies can be interpered to mean..  if
> > > > you create
> > > > a blank file on one of our
> > > > computers said company/org owns it....
> > > >
> > > > Have you gotten to Interface design or layout...?
> > > >
> > > > I'm developing a OO based layout for PHP sites/applications.
> > > > Somewhat of a template system. NukeLayout PHP Class
> > > >
> > > > It may provide a layout template...
> > > >
> > > > talk with you later
> > > >
> > > > "Brian K. Jones" wrote:
> > > > > Hey,
> > > > >
> > > > > sorry for the delay - interesting story behind it.
> > > > >
> > > > > As more and more work has been done on PHAT, I've built a
> > > > > foundation for further design and development, and the
> > > > > skeleton of PHAT that exists now is enough to get a taste of
> > > > > what it will eventually do, and it's spurred some excitement
> > > > > here in the office.
> > > > >
> > > > > We, as a team, go to a lot of 'interest group' meetings for
> > > > > the benefit of the campus's various departmental
> > > > > administrators and
> > > >
> > > > such,
> > > >
> > > > > and we've also had tons of network equipment vendor visits,
> > > > > as we've just ended the process of buying a new core switch.
> > > > >
> > > > > In these various interactions, we inevitably discuss things
> > > > > like the management tools available, and we always ask the
> > > > > vendors to supply us with their SNMP implementation details.
> > > > > In the process, PHAT has come up in conversation quite a bit,
> > > > > and it's caught the interest of a lot of people (which is
> > > > > good, I guess).
> > > > >
> > > > > The reason for the delay basically was that it was brought to
> > > > > my attention that the potential existed to generate patent
> > > > > revenues for the department, provided I close the source and
> > > > > all that stuff.  I argued that that would only delay
> > > > > development, and result in a less-than-worthy product that
> > > > > nobody would really want to maintain
> > > >
> > > > by
> > > >
> > > > > themselves... blah, blah, blah.  So I've been going over this
> > > > > with
> > > >
> > > > my
> > > >
> > > > > boss (who is a great guy and supports my decision 100%), and
> > > >
> > > > finally,
> > > >
> > > > > I was comforted in knowing that not only would our group and
> > > > > department not have our reputation tarnished by this
> > > > > decision, but that the faculty and management of the
> > > > > department are behind open source 100% as well (well, most of
> > > > > them are).  I guess I felt more pressure than was necessary -
> > > > > it was only a suggestion in the first place.  I'm new here -
> > > > > so I guess I took it too seriously.
> > > > >
> > > > > Anyway, I'll be writing soon to tell you about what's going
> > > > > on the technical front, as I'd like your input on some of
> > > > > this stuff.  Hope you'll hang in there.
> > > > >
> > > > > Also, since the final decision has been made, I'll start
> > > > > advertising the project a bit more in the coming weeks.
> > > > >
> > > > > Later.
> > > > > --
> > > > >
> > > > > Brian K. Jones
> > > > > System Administrator
> > > > > Dept. of Computer Science, Princeton University
> > > > > jo...@cs...
> > > > > Voice: (609) 258-6080
> > > >
> > > > --
> > > > Chauncey Thorn                  Internet: ct...@wt...
> > > > Linux Administrator - MCP      http://PCCS-Linux.COM
> > > > --------------------------------------------------------------
> > > > "Views expressed by this individual may differ from your
> > > > own..."
>
> --
>
> Brian K. Jones
> System Administrator
> Dept. of Computer Science, Princeton University
> jo...@cs...
> Voice: (609) 258-6080

--
Chauncey Thorn                  Internet: ct...@wt...
Linux Administrator - MCP       http://PCCS-Linux.COM
--------------------------------------------------------------
"Views expressed by this individual may differ from your own..."

[PHAT-devel] Re: phat

[Brian K. J. <jonesy@CS.Princeton.EDU>]

On Wednesday 24 April 2002 07:17 pm, you wrote:
> How are you doing?

Good.  I was sick yesterday - so I'm better :)

> Cool... I'm looking forward to seeing what you have...
> I have a collection of OIDs... will look for them.

Great.  By the way, If you go to sourceforge.net/projects/phat, you'll=20
notice that yesterday I posted a very informal overview and design=20
spec, and also posted a help wanted for another analyst/designer.  I=20
figure we have the development parts pretty much down now, and there=20
aren't many developers with the vision to start pretty much from=20
scratch like we're doing anyway.  More developers will probably join=20
once there's some code to play with.

>
> When you say modules for every sysOID. Do you mean creating include
> files that contain oids for a particular device..

That's exactly right, but only where it's absolutely necessary.  The=20
standard stuff is easy, since, for example, everything has a 'system'=20
branch :)
>
> e.g.
> sysOID_common.oids - OIDs that will extract from any device
> sysOID_netware.oids - contains netware stuff...
> sysOID_cisco_1600c.oids - contains
> sysOID_apache.oids

The naming convention can, I guess, be pretty intuitive to the end=20
user.  If necessary, we can have the program grab a sysOID live and=20
have it look for the actual file name that corresponds to the ID in a=20
lookup table.  So we can actually say, for a 3Com 3300:=20
'3com3300.inc.php'.  Then, when the program finds a sysOID of=20
43.22.1.14, it can look it up in the database and it'll match up with=20
the file name.  The part that became a little tricky was that I=20
realized that '43' is just a vendor's enterprise mib branch=20
assignment.  You get to the model using the numbers that come after=20
that.

>
> This way I can submit the proprietary vendor OIDs for the devices I
> have access to.

That would be awesome.  Are these devices you have access to?  I can=20
write up the modules and everything, but there may be some things I=20
don't have available to me to test against. =20


>
> Are you wanting to focus on network devices (Routers, switchers...)
> only or include support
> for any type of network device?.

Well, I think supporting anything with a network connection is a good=20
goal, and that's what we're going for in my eyes.  I'm starting with=20
switches and routers because those are by far the hardest, since=20
every technology on a network has to be supported, or at least not=20
hindered by, these devices.  Probably while we're working on those,=20
we'll take a break from the madness and write modules for things like=20
the ucd or sun agents that typically live on hosts, try to work with=20
the application specific agents like the one for apache, etc.  As=20
developers join, they'll certainly have their favorite toys to play=20
with...  The job is slightly larger for whoever wants to do stuff=20
that isn't a switch right away -- there's no interface or anything --=20
so they'll need to do some design work as well :)


>
> What type of data are you planning on storing in the db?
> Will I be able to search for a device by name and make changes/view
> that device data?

Yep.  The challenge here is that it's tough to know what things a user=20
will want to change.  The database is there to improve the=20
performance, and in some cases, aggregate data that would otherwise=20
take a week to grab live, and then aggregate all in the code (and who=20
wants to write that code anyway).  It'll mostly hold data that's=20
considered relatively static -- how often does the ifMTU change for a=20
given interface?  Likely never, unless you have a very old device=20
that you're planning to run multicast over or something :)
>
> Oh... Have you defined the required coding style?

Not really.  What are YOUR thoughts on this?  The code that actually=20
is working now is kind of crude and simple.  It gets the job done,=20
but it's not the prettiest code in the world, because once I got one=20
feature working, I immediately moved on to the next.  I'm a stickler=20
for 'clean code'.  I'd like to keep presentation and logic as=20
separate as possible, and have recently been reading about a couple=20
of new ways to do this.  However, I don't want the code to become=20
completely non-intuitive to other developers or myself in the=20
process.  Advisory comments and suggestions are more than welcome, as=20
they are for every other aspect of the project - as always.

I've said a lot here, but there's even more stuff in the design spec. =20
You really should read it - it'll probably give you more questions to=20
ask or ideas, which would be helpful.  If you have 'critical=20
questions' to add to the list of questions that PHAT tries to solve,=20
let us all know.  One question I didn't address was 'when will there=20
be code to look at'?  Well, read the design spec and you'll see what=20
the major holdup is.  It's a pain in the butt now, but will make the=20
overall tool much more flexible, and the code will be even easier to=20
write.
>
> Later..
> CT
Later,
/brian
>
> jonesy@CS.Princeton.EDU wrote:
> > I've done some of the layout, but most of it is just sort of a
> > breeding ground for ideas, not really what I would consider a
> > prototype look for a finished product.  I would say, though, that
> > it seems to be shaping up to look more like an application and
> > less like a website. I'll post some screenshots.
> >
> > I'd like your input on some of the behind-the-scenes code
> > organization, as some things have been troubling me.  Let me
> > update you on where I'm at now.
> >
> > I'm actually in the middle of doing almost nothing but
> > data-finding and database design (again).  I decided to switch
> > from using MySQL to PostgreSQL, because I'd really like to take
> > advantage of things like views, foreign keys, and the
> > network-specific datatypes.
> >
> > At the same time, I'm also doing some interface 'sketching' in an
> > effort to flesh out as much of the app in my head and on paper as
> > I can before we get started on coding what will be the finished
> > product.
> >
> > One challenge is going to be writing modules for every sysOID.=20
> > Every vendor implements different standard mibs (though some are
> > consistent), and a lot of the REALLY cool information is locked
> > up in proprietary vendor mibs.  All of these mibs contain similar
> > information, but it's a matter of getting it out no matter what
> > make and model it is.
> >
> > I'm at home today, but after this weekend I'll put up the code to
> > SF so you can grab it and see the sort of structure it's starting
> > to take.  I can also post some screen shots in the event that you
> > don't have any devices to run this against and get meaningful
> > data.
> >
> > Later.
> >
> > Quoting Chauncey Thorn <ct...@wt...>:
> > > How are you doing?
> > >
> > > Glad to hear from you.
> > > I've worked for a company that raised a similar topic. Not much
> > > you can
> > > do if you're coding
> > > on their clock, using their editor running on whatever OS.
> > >
> > > Most Network/Account policies can be interpered to mean..  if
> > > you create
> > > a blank file on one of our
> > > computers said company/org owns it....
> > >
> > > Have you gotten to Interface design or layout...?
> > >
> > > I'm developing a OO based layout for PHP sites/applications.
> > > Somewhat of a template system. NukeLayout PHP Class
> > >
> > > It may provide a layout template...
> > >
> > > talk with you later
> > >
> > > "Brian K. Jones" wrote:
> > > > Hey,
> > > >
> > > > sorry for the delay - interesting story behind it.
> > > >
> > > > As more and more work has been done on PHAT, I've built a
> > > > foundation for further design and development, and the
> > > > skeleton of PHAT that exists now is enough to get a taste of
> > > > what it will eventually do, and it's spurred some excitement
> > > > here in the office.
> > > >
> > > > We, as a team, go to a lot of 'interest group' meetings for
> > > > the benefit of the campus's various departmental
> > > > administrators and
> > >
> > > such,
> > >
> > > > and we've also had tons of network equipment vendor visits,
> > > > as we've just ended the process of buying a new core switch.
> > > >
> > > > In these various interactions, we inevitably discuss things
> > > > like the management tools available, and we always ask the
> > > > vendors to supply us with their SNMP implementation details.=20
> > > > In the process, PHAT has come up in conversation quite a bit,
> > > > and it's caught the interest of a lot of people (which is
> > > > good, I guess).
> > > >
> > > > The reason for the delay basically was that it was brought to
> > > > my attention that the potential existed to generate patent
> > > > revenues for the department, provided I close the source and
> > > > all that stuff.  I argued that that would only delay
> > > > development, and result in a less-than-worthy product that
> > > > nobody would really want to maintain
> > >
> > > by
> > >
> > > > themselves... blah, blah, blah.  So I've been going over this
> > > > with
> > >
> > > my
> > >
> > > > boss (who is a great guy and supports my decision 100%), and
> > >
> > > finally,
> > >
> > > > I was comforted in knowing that not only would our group and
> > > > department not have our reputation tarnished by this
> > > > decision, but that the faculty and management of the
> > > > department are behind open source 100% as well (well, most of
> > > > them are).  I guess I felt more pressure than was necessary -
> > > > it was only a suggestion in the first place.  I'm new here -
> > > > so I guess I took it too seriously.
> > > >
> > > > Anyway, I'll be writing soon to tell you about what's going
> > > > on the technical front, as I'd like your input on some of
> > > > this stuff.  Hope you'll hang in there.
> > > >
> > > > Also, since the final decision has been made, I'll start
> > > > advertising the project a bit more in the coming weeks.
> > > >
> > > > Later.
> > > > --
> > > >
> > > > Brian K. Jones
> > > > System Administrator
> > > > Dept. of Computer Science, Princeton University
> > > > jo...@cs...
> > > > Voice: (609) 258-6080
> > >
> > > --
> > > Chauncey Thorn                  Internet: ct...@wt...
> > > Linux Administrator - MCP       http://PCCS-Linux.COM
> > > --------------------------------------------------------------
> > > "Views expressed by this individual may differ from your
> > > own..."

--=20

Brian K. Jones
System Administrator
Dept. of Computer Science, Princeton University
jo...@cs...
Voice: (609) 258-6080

[PHAT-devel] update and thoughts

[Brian J. <bri...@wr...>]

Hi all,

This is for anyone who doesn't know the current status of PHAT.  I know there haven't been any releases... it's all part of the plan.  :-)

Admittedly, some of the networking portions of the code had to be put on hold as I had some other pressing issues at work.  However, in the process of working with elgersma on an unrelated internal project, we came up with the idea of actually using the code for that project as the base for the PHAT modules.  That code is all elgersma's - which I guess pretty much puts him in charge of the presentation portions of the code (congrats :P).  We'll have some more work to do and maybe some tweaking to get it right, but it's progress.

I have been, on and off, testing some of the many php application 'frameworks' you can find all over freshmeat and sourceforge.  I was searching for something the modules could be written *to* - but I think elgersma's code largely does away with some of that need.

As for the database abstraction layer, I'm finding more and more 'immaturities' in ADODB as I work with it, mostly at home.  For example, it doesn't have the ability to create a new database.  There's some other quirkiness in it as well. I'm thinking that we should get a functioning product FIRST, and worry about cross-platform, cross-database, cross-whatever later (though we *can* plan and design with it in mind, so it's not an afterthought).

Since we do all of our development here with MySQL, that'll be the first database supported.  As for platforms, there are a couple of features I'd like to have in PHAT that may depend on UNIX, and I don't have a Windows development box (that's an oxymoron) to make sure all the PHP functionality will work there under IIS.

So basically, PHAT begins life as a LAMP application?  Well, yeah. It's a setup many users are pretty comfortable with, so I don't feel too bad about that.  As we attract more developers/users, some other people can test it on other platforms and help port it elsewhere.

thoughts? flames?  
/njcajun
-- 

_______________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup

[PHAT-devel] hi - update

[Brian K. J. <jonesy@CS.Princeton.EDU>]

Hi,


This email is really to serve as a welcome to cthorn, who just joined=20
the list this weekend, and to update the general state of PHAT.

Sorry I haven't released the stuff that I've been working on.  I've=20
gotten the beginnings of a function collection together.  By itself,=20
it's not very useful - I just wanted to put them together in one file=20
for easy reference.  Together with a couple of small tools I've=20
written (to be released this week), they become somewhat useful, but=20
the tools need to be a bit more 'global' - they need to be tested=20
with more types of hosts and switches.  On my network, with what I=20
have, I can answer the following questions from my browser:

1.  What port on switch x is host y on?  (this will lead to the=20
ability to shut down that port if there's unwanted/out of control=20
traffic, or an unauthorized/unregistered host on your network, or=20
whatever).  This takes a switch name (hostname only) and the host can=20
be in the form of an IP, MAC or hostname.

2.  Give me the basic information about host x.  OS version,=20
interfaces, is it forwarding, etc. (identifying information), and=20
also port scan the host.  This will lead to the creation of an alert.=20
 The host will be portscanned, and the open ports will be databased. =20
When the open ports change for that host, you will be notified via an=20
alert, which could appear on the front page as a sidebar item.

3.  For this switch, show me all of the hosts that the switch sees on=20
each port.  This tool is immature right now.  It just spits out tons=20
of information, and it's not formatted.  Also, for ports that may=20
carry traffic for multiple hosts, it doesn't identify which of those=20
has a direct physical connection, and which ones are just sort of=20
'transient' traffic.  I'm working on that now.

The other thing I'm working on is the design of the database, which=20
is getting a bit bigger.  I'll post the schema this week so you can=20
get a look at where it's going.  In parallel, I'm also working on the=20
initial population of the database.  The database layer is handled=20
completely by ADODB right now, which is an OO-based database=20
abstraction layer for PHP.  However, I'm still getting used to it, so=20
development in this area is a bit slower, as it requires constant=20
RTFM on my part :)

To give an idea of what everyone does and the flow of the code on=20
this side, this is how it has been going:

tengi hacks up very quick (but amazingly useful and accurate)=20
prototypes of tools that he actually uses day-to-day.  This serves as=20
the research/prototype for most of my php.  I take his csh or perl=20
(or whatever he feels like scripting in today) and transpose the code=20
into PHP, possibly adding functions as I go, since the web interface=20
may be conducive to adding features, and usually Chris is hacking=20
stuff together in 10 minutes and I'm spending a day picking his brain=20
and 'webifying' it.  He's a genius :)

elgersma has been running web servers since the pre-apache days, and=20
has been coding php since 1.0, not to mention he's good with MySQL,=20
which we're using for development.  He's a big help in designing and=20
integrating all of these tools, and knows how to do plenty of stuff I=20
can't, like taking our building map and generating pictures that=20
overlay the map and show us what room some unregistered host is=20
actually living. =20

My job has basically been to bug both of these guys constantly for=20
their expertise, and try to put something useful together out of it. =20
elgersma and I share an office, which is good because we bounce a lot=20
of ideas off eachother, and he's working on tools that will be=20
integrated later on, so we serve as peer review for eachother, and=20
also, since we work on some different stuff, the core of the=20
application will likely be as generic as possible to allow for both=20
of our code.  This is also one of the reasons that 'Modular Design'=20
was at the top of the requirements list.

elgersma and tengi may have amendments or corrections to this, but=20
from where I sit, that's pretty much how it goes :-)

My goal for this week is to get the database schema, function=20
collection and associated tools posted to sourceforge so everyone can=20
tinker and improve upon it, or flame me so I can make it better :)

brian


--=20

Brian K. Jones
System Administrator
Dept. of Computer Science, Princeton University
jo...@cs...
Voice: (609) 258-6080