Monday, November 21, 2005

Deleting a message from the Postfix queue

The postsuper command has an option to delete Postfix message queue files. To delete the message with queue id ABCDEF, perhaps obtained from mailq output, one would use:

# postsuper -d ABCDEF

To delete a large number of files one would use:

# postsuper -d - < filename-with-queue-ids

To delete all messages in queue:

#postsuper -d ALL
http://www.postfix.org/faq.html

access-list syntax

address-list acl_name deny permit protocol src_addr src_mask dest_addr dest_mask dest_operator dest_port

access-group acl_name in interface in_name

Thursday, November 17, 2005

How to Delete Messages from Queues in Exchange Server 2003



1. Click Start, point to All Programs, point to Microsoft Exchange, and then click System Manager.


2. Double-click Servers, double-click the server that you want, and then click Queues.


3. Right-click the queue that you want to modify, and then click Freeze to freeze the queue.


4. Click Find Messages, and then click Find Now to find messages in the queue.


5. Right-click the message that you want to delete, and then click one of the following options:
• Click Delete (no NDR) to delete messages from the queue without sending a non-delivery report (NDR) to the senders.
• Click Delete (with NDR) to delete messages from the queue and send an NDR to the senders of the messages.

Access lists on the PIX firewall can only be applied to traffic entering an interface, not traffic that is exiting an interface. This is unlike Cisco router, on which access lists can be applied in either direction.

The syntac for access lists on the PIX firewall is ver similar to that of Cisco routers. The key difference is that access lists on the PIX firewalls use standard wildcard masks, whereas on routers they use inverse wildcard masks. For example, when blcoking a 24-bit subnet, you would use a mask of 255.255.255.0 on a PIX firewall and a mask of 0.0.0.0.255 on Cisco router.

To let traffic flow from a high security level to a lower level, use the nat and global commands. For the opposite direction, from lower to higher, use the static and access-list commands.

The design of an access list should start with a definition of what is going to be allowed and then proceed to what is going to be denied.

A good practice is to add an explicit deny all statement to the end of an access list so you remember it is there when yu do a show access-list command. You can see how many packets

Inbound traffic is lower security-level to higher security-level

Outbound traffic is higher security-level to lower security-level

Tuesday, November 15, 2005

On some RedHat AS 3.0 installations, laus/audit.d logs 20M a day and never logrotates. You can just do the following:

/etc/init.d/audit stop
rpm -f /dev/auditrpm --erase laus
/etc/init.d/crond restart
/etc/init.d/atd restart
rm -rf /var/log/audit.d

I've got some bounced mail in the queue which is not being accepted by the remote site. How can I remove it from the queue?

postfix stop
find /var/spool/postfix -name queue-id -print xargs rm
postfix start

Monday, November 14, 2005

http://www.netcraftsmen.net/welcher/papers/pix01.html


If we have global Internet addressing and do not wish to re-address our computers, we can assign NAT ID 0 within the PIX to disable NAT.

We generally put a global command on each lower security interface we want our internal users to have access to, although statics can be preferable for internal-internal access (see below). The main decision (other than addressing design) is whether to use one or multiple NAT ID's. Using unique NAT ID's limits access to specific interfaces. Using one NAT ID is simpler and assumes the PIX will sort out which nat command (below) pairs up with which global command on which interface.

We put nat commands on the higher security interfaces, allowing users to start connections to lower security level interfaces with global commands on them. The NAT ID ties the inside addresses in the nat command to the pool of addresses in one or more global commands with the same NAT ID.

Port Address Translation is where all inside addresses appear as one outside address, with shifted ports. PAT has some restrictions, for example it cannot support H.323 or caching nameserver use, so you may want to use it to augment a range of global addresses rather than using it as your sole global address.

The static command creates a permanent mapping (called a static translation slot or "xlate") between a local IP address and a global IP address.

Use the static and access-list commands when you are accessing an interface of a higher security level from an interface of a lower security level.

When NAT exists between two interfaces the command takes the form of "static (high,low) low high" . Without address translation, the format of the static command becomes different: "static (high,low) high high".

TIP: If you use statics you will also be able to go from higher to lower without having to use nat and global. Example: suppose management station 10.2.2.2 (NMS) needs to talk to serv1 at 10.1.1.15 on the inside. Configure:

static (inside,management) 10.1.1.15 10.1.1.15 netmask 255.255.255.255 access-list from- management-coming-in permit tcp host 10.2.2.2 host 10.1.1.15 eq 8888 access-group from-management-coming-in in interface management
Because the static exists, 10.1.1.15 can also inititate connections to 10.2.2.2 but cannot talk to 10.2.2.50 (NMS2) because no method of translation exists.

Another example:

static (inside,management) 10.1.1.0 10.1.1.0 netmask 255.255.255.0

This allows each network to address the other. The inside can then talk to everything on the management net and reply packets are let back through by virtue of stateful inspection but an ACL must exist for the management net to initiate anything to the inside. There are some other variations one can do, but statics are more clear and you can predict behaviour because no timeouts for the connections exist and you still retain ultimate control via the ACL.

Wednesday, November 09, 2005

Booting into a Graphical Environment

D.4.3. Booting into a Graphical Environment
If you have installed the X Window System but are not seeing a graphical desktop environment once you log into your Red Hat Linux system, you can start the X Window System graphical interface using the command startx.
Once you enter this command and press [Enter], the graphical desktop environment is displayed.
Note, however, that this is just a one-time fix and does not change the log in process for future log ins.
To set up your system so that you can log in at a graphical login screen, you must edit one file, /etc/inittab, by changing just one number in the runlevel section. When you are finished, reboot the computer. The next time you log in, you will have a graphical login prompt.
Open a shell prompt. If you are in your user account, become root by typing the su command.
Now, type gedit /etc/inittab to edit the file with gedit. The file /etc/inittab will open. Within the first screen, you will see a section of the file which looks like this:

# Default runlevel. The runlevels used by RHS are:
#   0 - halt (Do NOT set initdefault to this)
#   1 - Single user mode
#   2 - Multiuser, without NFS (The same as 3, if you do not have networking)
#   3 - Full multiuser mode
#   4 - unused
#   5 - X11
#   6 - reboot (Do NOT set initdefault to this)
#
id:3:initdefault:


To change from a console to a graphical login, you should change the number in the line id:3:initdefault: from a 3 to a 5.

Warning

     Your changed line should look like the following:
Change only the number of the default runlevel from 3 to 5.
id:5:initdefault:

When you are satisfied with your change, save and exit the file using the [Ctrl]-[x] keys. You will see a message telling you that the file has been modified, and asking you to confirm your change. Type [Y] for yes.
Now, your next login after reboot will be from the graphical screen.