Free sg software for linux

The SunGazer Packetfilter is a small and simple tool to set up firewall rules. It works with iptables and is easy to use and configure.
You can set up the SunGazer Packetfilter with /etc/sg-packetfilter/sg-packetfilter.config
Please note the notice lines in the file.
To install follow these steps:
As user:
1. Type tar xvfz sg-packetfilter-X.X.X.tar.gz
or tar xvfj sg-packetfilter-X.X.X.tar.bz2.
2. Type cd sg-packetfilter-X.X.X.
3. Change with su root to root.
As root:
4. Type sh install.sh to install the main script.
5. Go to /etc/sg-packetfilter/ and configure the file
sg-packetfilter.config with your favorite editor.
SunGazer Packetfilter requires the following:
- kernel >= 2.4
- iptables netfilter modules -> kernel
- iptables >= 1.2
- bash
Enhancements:
- adjusted forward chain
- added rule for smtp
- added rule for pop3
- added rule for pop3s
- added rule for imap4
- added rule for imap4s
- added rule for ssh
- added rule for rsync
- added rule for active ftp
- added rule for passive ftp

FFmpeg::Stream is an audio or video stream from a (multi)media file.

SYNOPSIS

$ff = FFmpeg->new(); #see FFmpeg
#...
$sg = $ff->create_streamgroup(); #see FFmpeg
$st = ($sg->streams())[0]; #this is a FFmpeg::Stream

FFmpeg::Stream objects are not instantiated. Rather, objects are instantiated from FFmpeg::Streams subclasses FFmpeg::Stream::Video for video streams, FFmpeg::Stream::Audio for audio streams, and FFmpeg::Stream::Data for streams containing neither audio nor video data. Streams identified in the file whose content type cannot be determined are represented by FFmpeg::Stream::Unknown objects.

Access FFmpeg::Stream objects using methods in FFmpeg::StreamGroup. See FFmpeg::StreamGroup for more information.

This class has attributes applicable to any stream type in a multimedia stream, or stream group. FFmpeg-Perl represents multimedia stream group information in a FFmpeg::StreamGroup object, which is a composite of FFmpeg::Stream objects.

FFmpeg::Stream objects dont do much. They just keep track of the media streams ID within the multimedia stream group, and hold an instance to a FFmpeg::Codec object if the codec of the stream was deducible. See FFmpeg::Codec for more information about how codecs are represented.

FFmpeg::Stream::Audio is an audio stream from a (multi)media stream group.

SYNOPSIS

$ff = FFmpeg->new(); #see FFmpeg
#...
$sg = $ff->create_streamgroup(); #see FFmpeg
$st = ($sg->streams())[0]; #this is a FFmpeg::Stream

Objects of this class are not intended to be instantiated directly by the end user. Access FFmpeg::Stream::Audio objects using methods in FFmpeg::StreamGroup. See FFmpeg::StreamGroup for more information.

This class represents an audio stream in a multimedia stream group, and has audio-specific attributes. General stream attributes can be found in the FFmpeg::Stream class.

Linux Inventory Aggregator is designed to be a simple, self-contained (as much as possible) script for gathering hardware information.

Sample Output

In the first example, a stock Mandrake system is shown with a single processor, 386MB of memory, an attached SCSI disk array, and several internal IDE drives.

[rtwomey@gamma inventory]$ ./get_inventory.pl
Statistics of machine gamma
* 1 CPU: Pentium III (Coppermine) @ 863.955MHz
* Kernel: 2.6.11-6mdk #1 Tue Mar 22 16:04:32 CET 2005
* Memory total: 385668kB
* Hostname: gamma @ 192.168.1.3
* Network Interfaces:
lo: 127.0.0.1
eth0: 192.168.1.3
* Graphics card: nVidia Corporation NV15 [GeForce2 GTS/Pro] (rev a3)
* Network controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 78)
* Network controller: Linksys NC100 Network Everywhere Fast Ethernet 10/100 (rev 11)
* Sound card: Creative Labs SB Live! EMU10k1 (rev 07)
* SCSI card: QLogic Corp. ISP12160 Dual Channel Ultra3 SCSI Processor (rev 06)

Attached IDE disks:
* Disk hdg: size: 81964302336 bytes (81GB), model: Maxtor 4R080L0
* Disk hdf: size: 30900215808 bytes (30GB), model: Maxtor 93073U4
* Disk hde: size: 164696555520 bytes (164GB), model: HDS722516VLAT80
* Disk hdc: size: 123522416640 bytes (123GB), model: IC35L120AVV207-0
* Disk hdb: size: 120034123776 bytes (120GB), model: WDC WD1200JB-75CRA0
* Disk hda: size: 45191946240 bytes (45GB), model: IBM-DTLA-307045

Attached SCSI disks:
* Disk sda: SEAGATE ST318452LC (Channel: 00 ID: 08 Lun: 00)
* Disk sdb: SEAGATE ST318453LC (Channel: 00 ID: 09 Lun: 00)
* Disk sdc: SEAGATE ST336607LC (Channel: 01 ID: 08 Lun: 00)
* Disk sdd: SEAGATE ST336607LC (Channel: 01 ID: 09 Lun: 00)
* Disk sde: SEAGATE ST336607LC (Channel: 01 ID: 11 Lun: 00)
* Disk sdf: SEAGATE ST336607LC (Channel: 01 ID: 12 Lun: 00)
* Disk sdg: SEAGATE ST318453LC (Channel: 01 ID: 13 Lun: 00)
* Disk sdh: SEAGATE ST318452LC (Channel: 01 ID: 14 Lun: 00)

The second example illustrates a dual-processor Xeon system (note that HyperThreading causes the 2 processors to appear as 4):

[rtwomey@babbage inventory]# ./get_inventory.pl
Statistics of machine babbage
* 4 CPUs: CPU1 = Intel(R) Xeon(TM) CPU 2.80GHz @ 2791.744MHz; CPU2 = Intel(R) Xeon(TM) CPU 2.80GHz @ 2791.744MHz; CPU3 = Intel(R) Xeon(TM) CPU 2.80GHz @ 2791.744MHz; CPU4 = Intel(R) Xeon(TM) CPU 2.80GHz @ 2791.744MHz
* Kernel: 2.6.9-11.ELsmp #1 SMP Fri May 20 18:26:27 EDT 2005
* Memory total: 514484kB
* Hostname: babbage @ XXX.XXX.XXX.XXX
* Network Interfaces:
lo: 127.0.0.1
eth0: XXX.XXX.XXX.XXX
* Network controller: Intel Corporation 82544GC Gigabit Ethernet Controller (LOM) (rev 02)
* SCSI card: LSI Logic / Symbios Logic 53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI (rev 07)
* SCSI card: LSI Logic / Symbios Logic 53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI (rev 07)
* Graphics card: ATI Technologies Inc Rage XL (rev 27)

Attached SCSI disks:
* Disk sda: SEAGATE ST373307LC (Channel: 00 ID: 00 Lun: 00)
* Disk sdb: SEAGATE ST39103LC (Channel: 00 ID: 01 Lun: 00)
* Disk sdc: SEAGATE ST39204LC (Channel: 00 ID: 03 Lun: 00)
* Disk sdd: SEAGATE ST39204LC (Channel: 00 ID: 04 Lun: 00)

The third example illustrates an IDE CD-RW, as well as a SATA disk that is handled via the Linux sg driver:

[rtwomey@younger inventory]# ./get_inventory.pl
Statistics of machine younger
* 2 CPUs: CPU1 = Intel(R) Pentium(R) 4 CPU 3.00GHz @ 2992.825MHz; CPU2 = Intel(R) Pentium(R) 4 CPU 3.00GHz @ 2992.825MHz
* Kernel: 2.6.9-16.ELsmp #1 SMP Mon Aug 15 20:06:02 EDT 2005
* Memory total: 1033192kB
* Hostname: younger @ XXX.XXX.XXX.XXX
* Network Interfaces:
lo: 127.0.0.1
eth0: XXX.XXX.XXX.XXX
* Sound card: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC97 Audio Controller (rev 03)
* Graphics card: ATI Technologies Inc RV370 5B60 [Radeon X300 (PCIE)]
* Network controller: Broadcom Corporation NetXtreme BCM5751 Gigabit Ethernet PCI Express (rev 01)

Attached IDE disks:
* CD-RW drive: HL-DT-ST CD-RW/DVD-ROM GCC-4482B

Attached SCSI disks:
* ATA ST340014AS (Channel: 00 ID: 00 Lun: 00)

DrKnock project is a port knocking solution based on sig2knock by Cappella and Tan Chew Keong (http://www.security.org.sg/code/portknock1.html).
Right now, the only functional improvement over sig2knock is the ability to use the client under Windows XP SP2. The client and server work on both Unix and Windows.
Enhancements:
- A code cleanup was undertaken and bugs were fixed.
- The last occurrences of sig2knock were replaced by drknock, including the Windows service name and log file.

Lib3df is a C++ library to load 3D world. It works under Windows,MacOS,Linux and most Unixes.

HLIB is a C++ library intended to facilitate the use of ".MAP" files in applications. ".MAP" files are produced by the "Valve Hammer Editor" availlable at: http://collective.valve-erc.com/ . This is the editor used to create Half-Life, Team Fortress Classic, Counter-Strike and Day of Defeat maps. A lot of models are availlable in this format on the internet and the abillity to read such format may greatly help game programmer. HLIB is intended to be portable accross many platforms including: GNU/Linux, All UNIX*S, MS-Windows > 95.

HOW IT WORKS:

HLIB doesnt impose you anything about how the map data will be presented in memory. Instead the library calls the methods of a "builder" object you supplied, to inform your program that some kind of 3D objects has been found in the map file. For instance when the library finds a polygon it calls:

BeginPolygon(); then all subsequent method call will refer to this polygon.

When there is no more data about the polygon, the library calls: EndPolygon();

A map is made of many entities. Each entity can have many key-value pairs (such as: "classname" "player", which says: this entity is of class player). In addition, an entity can have some brushes. A brush is a convex set of polygons. Each polygon has:

- one texture name
- at least 3 vertex
- one normal per vertex
- one UV coordinate per vertex

First you have to create a "builder". You do this by subclassing the
HLMapBuilder class:

class MyBuilder
: public HLMapBuilder
{
public:
MyBuilder(void) {}
virtual ~MyBuilder(void) {}
}

Then you have to create an HLMap object and a builder and link them together:

HLMap theMap;
MyBuilder theBuilder
theMap.SetBuilder(theBuilder);

std::ifstream theMapFile("mymap.map");
theMap.BuildFromStream(theMapFile);

The HLMap object will parse the file and call the following methods of the builder
object:

// Cancel everything (error)
virtual void BuildError(void);
// Begins a map building
virtual void BuildBeginMap(void);
// Begins an entity building
virtual void BuildBeginEntity(void);
// Builds an option
virtual void BuildOption(const char* option, const char* value);
// Begins a brush building (an entity may have many brushes)
virtual void BuildBeginBrush(void);

// Builds a facet (deprecated)
virtual void BuildFacet(sgVec3 A, sgVec3 B, sgVec3 C, const char* texture, sgVec3 U, int ushift, sgVec3 V, int vshift, float rotation, float xscale, float yscale);

// Begins a polygon building
virtual void BuildBeginPolygon(void);
// Builds the polygons texture
virtual void BuildTexture(const char* texture);
// Get the last built texture height and width
virtual void GetTextureDimension(int* w, int* h);
// Builds one polygons vertex
virtual void BuildNormal(sgVec3 v);
// Builds one polygons vertex
virtual void BuildVertex(sgVec3 v);
// Builds the vertex UV mapping
virtual void BuildUVMapping(sgVec3 uv);
// Ends a polygon building
virtual void BuildEndPolygon(void);
// Ends a brush building (an entity may have many brushes)
virtual void BuildEndBrush(void);
// Ends an entity building
virtual void BuildEndEntity(void);
// Ends a map building
virtual void BuildEndMap(void);

Here is the list of method call produced for a map containing only a single
pyramidal object:

BuildBeginMap(); // this is a new map
BuildBeginEntity(); // this is a new entity
BuildOption("classname", "pyramid"); // this entitys classname is: "pyramid"
BuildOption("name", "The Big Pyramid"); // this entitys name is: "The Big Pyramid"
BuildBeginBrush(); // this entity contains a brush
BuildBeginPolygon(); // lets go for the brushs first polygon
BuildTexture("GoodOldPyramid"); // it uses the good old pyramid texture
GetTextureDimension(&w, &h); // the builder has to give the with and height
// of the texture
/// it is needed because the HLMap object doesnt
// know anything about image file format
BuildVertex(v); // the first vertex
BuildNormal(n); // its normal
BuildUVMapping(uv); // its UV corrdinate

BuildVertex(v); // the second vertex
BuildNormal(n); // its normal
BuildUVMapping(uv); // its UV corrdinate

...
BuildEndPolygon(); // this polygon is finished

BuildPolygon(); // The second polygon
...
BuildEndPolygon(); // the second polygon is finished

...

BuildEndBrush(); // this brush is finished

BuildBeginBrush(); // a second brush
...
BuildEndBrush(); // the second brush is finished

...

BuildEndEntity(); // The first entity is finished
BuildBeginEntity(); // a second entity
...
BuildEndEntity(); // the second entity is finished

...
BuildEndMap(); // the map is finished

HLIB contains a HLMapBuilder class which is a basic builder. It doesnt do anything but donc break anything. It is the base class for all your builder. A real life builder is given in example with the PlibMapBuilder class. It is up to you to customize these methods to produce something
usefull. HLIB is just a parser with some 3D geometry CSG calculations.

Due to the file format, HLIB has to do a lot of 3D calculation when reading the map file. To help with these calculations HLIB uses PLIB. PLIB is a 3D library availlable at: http://sourceforge.net/projects/plib

PLIB is made of many components:

- SG: which deals with geometry and is used extensively throughout HLIB
- SSG: which deals with rendering
- UL: which is a utility library, (only used in HLIB for some defines)
- ....

HLIB uses SG internally and externally: the sgVec3 type is defined by SG and is used to pass vertex data from the director (HLMap) to the builder (HLMapBuilder derived classes).

HLIB uses SSG in one class only: PlibMapBuilder. You can safely remove this class if you dont want SSG at all.

MTX is a set of low level driver programs to control features of SCSI backup related devices such as autoloaders, tape changers, media jukeboxes, and tape drives.
MTX can also report much data, including serial numbers, maximum block sizes, and TapeAlert messages that most modern tape drives implement (to tell you the exact reason why a backup or restore failed), as well as do raw SCSI WRITE and READ commands to tape drives (not important on Linux, but important on Solaris due to the fact that the Solaris tape driver supports none of the additional features of tape drives invented after 1988).
MTX is designed to be a low level driver in a larger scripted backup solution, such as Amanda. mtx is not supposed to itself be a high level interface to the SCSI devices that it controls.
Main features:
- Will deal with LARGE media libraries (over a hundred elements).
- Supports multi-drive media changers such as the Exabyte 220 dual- drive tape library.
- Supports the invert bit for optical jukeboxes that need that in order to flip their media.
- Supports the eepos bits for libraries that need this to extend/retract their import/export tray.
- Now supports import/export elements!
- Reports volume tags (bar codes) and "alternate volume tags" (whatever those are!) for those tape libraries that support them.
- Now runs under FreeBSD and at least Solaris 8.
- Now has a man page!
- The actual SCSI manipulation has been separated out into a library, so that you can create your own "C" programs that manipulate SCSI media changers directly. (Please note: this is under GPL, so any such programs will have to be under GPL also).
Version restrictions:
- You may need to do a mt offline (or equivalent for your OS) on the tape drive to eject the tape before you can issue the mtx unload command. The Exabyte EZ-17 and 220 in particular will happily sit there snapping the robot arms claws around thin air trying to grab a tape thats not there.
- The next command does not understand the invert bit (i.e., does not recognize that for optical jukeboxes, the next of side one is to unload, invert, and reload the same disk). It always advances to the next slot instead.
- For some Linux distributions, you may need to re-compile the kernel to scan SCSI LUNs in order to detect the media changer. Check /proc/scsi/scsi to see whats going on.
- If you try to unload a tape to its source slot, and said slot is full, it will instead put the tape into the first empty slot. Unfortunately the list of empty slots is not updated between commands on the command line, so if you try to unload another drive to a full source slot during the same invocation of mtx, it will try to unload to the same (no longer empty) slot and will urp with a SCSI error.
- For big tape libraries (more than a couple dozen elements) this may set a big Allocation_Size in the SCSI command block for the REQUEST_ELEMENT_STATUS command. Some operating systems may not be able to handle this. Versions of Linux earlier than 2.2.6, in particular, may fail this request due to inability to find contiguous pages of memory for the SCSI transfer (later versions of Linux sg device do scatter-gather so that this should no longer be a problem).
- VMS and Tru64 support are probably irretrievably busted.
- This program will only use the first arm of multiple-arm robots unless the robot re-maps all arms to one element ID.
- It has been reported that this program works on Solaris 7 using the sst driver, and may work on Solaris 8 using the sgen driver. sst can be gotten from the Amanda contrib directory at http://download.sourceforge.net/amanda.
Enhancements:
- This release adds the scsieject utility.
- This utility is used to perform the SCSI operations start, stop, load, unload, lock, and unlock.
- It is primarily used with a data transfer device after loading media or before unloading media.
- Loaderinfo has been enhanced to provide more information.
- The mtx command previous has been implemented and the last command has been fixed.