Discuss

discuss@lists.centos.org

3 participants
34748 discussions

git.centos.org : Delayed migration
by Fabian Arrotin 05 Apr '19

05 Apr '19

Due to unexpected circumstances , we have to delay the git.centos.org migration. I'll post an update when we'll have all details, but it seems it would be only delayed for some days. Thanks for your comprehending, -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 56BEC54E | twitter: @arrfab

1 0

New post message
by Konstantin Msk 05 Apr '19

05 Apr '19

Hello! On my server PC i have Centos 7 installed. CentOS Linux release 7.6.1810. There are four arrays RAID1 (software RAID) md124 - /boot/efi md125 - /boot md126 - /bd md127 - / I have configured booting from both drives, everything works fine if both drives are connected. But if I disable any drive from which RAID1 is built the system crashes, there is a partial boot and as a result the Entering emergency mode. By all rules RAID1 in case of similar failure of one of disks the system has to recognize this moment at loading, analyze that from the array only one disk is available and forcibly assemble inactive RAID array in case it is degraded in the mode when the second disk is missing may be... In Debian system this problem does not occur, the initramfs runs the script /scripts/local-block/mdadm builds the array from one dostoinogo disc ( lack of drive is not important, it's either a drive failure or disconnection from power-random or not random). In this script You can see the following ...... if [ "$COUNT" = "$MAX" ] then # Poor man's mdadm-last-resort@.service for incremental devices mdadm -q --run /dev/md?* # And last try for all others mdadm -q --assemble --scan --run rm -f /run/count.mdadm.initrd .... Why in server Centos 7 this problem is still not solved? Will this be fixed in upcoming releases? Best Regards AndersonGH

3 6

Ark vs. RAR files under CentOS 7
by Nicolas Kovacs 05 Apr '19

05 Apr '19

Hi, Over the past weeks, I've configured and fine-tuned a bells-and-whistles desktop based on CentOS 7 and KDE, which I've documented in detail on my blog: * https://www.microlinux.fr/poste-de-travail-entreprise-centos-7-kde/ So far I have one single thing that's not working. It's a little detail, but I'm sure it will come bite me, since I know some of my users need this functionality. Ark (KDE's archive manager) can't handle RAR files, even though unrar is installed under the hood. It looks like I have to rebuild Ark to get this functionality. Before I do that, I thought I'd rather ask if there is a more straightforward solution to this. Some third-party repositories (like Nux-Dextop) offer rebuilt packages like k3b-freeworld or audacity-freeworld with extended functionality. Does anybody know of an ark-freeworld package that's out there somewhere? Cheers from the sunny South of France, Niki -- Microlinux - Solutions informatiques durables 7, place de l'église - 30730 Montpezat Site : https://www.microlinux.fr Mail : info(a)microlinux.fr Tél. : 04 66 63 10 32

1 0

Kickstart putting /boot on sda2 (anaconda partition enumeration)?
by Bryce Evans 04 Apr '19

04 Apr '19

Does anyone know how anaconda partitioning enumerates disk partitions when specified in kickstart? I quickly browsed through the anaconda installer source on github but didn't see the relevant bits. I'm using the centOS 6.10 anaconda installer. Somehow I am ending up with my swap partition on sda1, /boot on sda2, and root on sda3. for $REASONS I want /boot to be the partition #1 (sda1) My kickstart storage config looks like this: bootloader --location=mbr --driveorder=sda,sdb zerombr ignoredisk --only-use=sda,sdb clearpart --all --drives=sda,sdb part raid.boot0 --size 1000 --ondrive=sda part raid.swap0 --size 8192 --ondrive=sda part raid.root0 --size 8000 --grow --ondrive=sda part raid.boot1 --size 1000 --ondrive=sdb part raid.swap1 --size 8192 --ondrive=sdb part raid.root1 --size 8000 --grow --ondrive=sdb raid /boot --fstype ext4 --device md0 --level=RAID1 raid.boot1 raid.boot0 raid swap --fstype swap --device md1 --level=RAID1 raid.swap1 raid.swap0 raid / --fstype ext4 --device md2 --level=RAID1 raid.root1 raid.root0 The anaconda-ks.cfg file that gets written out to /root (after kickstart finishes) looks like this: #zerombr # The following is the partition information you requested # Note that any partitions you deleted are not expressed # here so unless you clear all partitions first, this is # not guaranteed to work #clearpart --all --drives=sda,sdb #ignoredisk --only-use=sda,sdb #raid /boot --fstype=ext4 --level=1 --device=md0 raid.008018 raid.008002 #raid swap --level=1 --device=md1 raid.008017 raid.008001 #raid / --fstype=ext4 --level=1 --device=md2 raid.008019 raid.008003 #part raid.008001 --size=8192 #part raid.008002 --size=1000 #part raid.008003 --grow --size=8000 #part raid.008017 --size=8192 #part raid.008018 --size=1000 #part raid.008019 --grow --size=8000 I'm assuming that my swap is being put on sda1 because for some reason that partition gets the lowest numeric value in the name (raid.008001) But I don't see why that is happening, nor am I sure how to tell anaconda that I want /boot on the first partition (other than doing it in %pre) I cannot specify the 'onpart=sda1' option because I use 'clearpart' in the script, and according to the docs: "If the clearpart command is used, then the --onpart command cannot be used on a logical partition." The partition table on disk ends up looking as such: bash-4.1# parted /dev/sda GNU Parted 2.1 Using /dev/sda Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) p Model: HP LOGICAL VOLUME (scsi) Disk /dev/sda: 480GB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 1049kB 8591MB 8590MB primary raid 2 8591MB 9640MB 1049MB primary ext4 boot, raid 3 9640MB 480GB 470GB primary raid Anyone know where I should be looking, or have a workaround besides doing my partitioning in %pre? Thanks

3 2

Re: [CentOS] nobody:nobody
by Mark LaPierre 03 Apr '19

03 Apr '19

On 4/3/19 6:43 AM, mark wrote: > On 04/02/19 20:21, Mark LaPierre wrote: >> Hey Y'all, >> >> For the last week or more I've been trying to get NFS and OpenLDAP to >> play nice with each other. I've pretty much worn the Google machine >> out trying to find a solution. I've found several that said "Solved" >> but none of those solutions solved my nobody:nobody problem. >> >> In the past I've used NFS in conjunction with NIS to share home >> directories from my NFS server but I read that NIS is deprecated in >> favor of LDAP so, being a sucker for new ideas, I decided I would use >> LDAP too like the big boys do. I think I'm regretting this decision. >> Now the question: >> >> Is there something I need to configure on the client side of the >> relationship that all the Google wisdom has failed to mention? All the > > I'd assume: have you edited /etc/idmapd.conf, and at least put in your > domain? Then started the imapd daemon? > > Btw, when you go to C 7, there's no imapd daemon, but you still need to > edit that file. > > mark >> guides/tutorial/etc... talk extensively about configuring the server, >> many giving conflicting information, but have nothing to say about the >> client. I've even found a couple that talk about configuring CentOS 6 >> but contain commands found only in CentOS 7. Makes one go hmmm? >> >> Here's the basic details: >> Server: >> CentOS 6 >> openldap-2.4.40-16.el6.i686 >> openldap-clients-2.4.40-16.el6.x86_64 >> perl-LDAP-0.40-3.el6.noarch >> sssd-ldap-1.13.3-60.el6_10.2.x86_64 >> openldap-2.4.40-16.el6.x86_64 >> openldap-servers-2.4.40-16.el6.x86_64 >> python-ldap-2.3.10-1.el6.x86_64 >> apr-util-ldap-1.3.9-3.el6_0.1.x86_64 >> smbldap-tools-0.9.6-4.el6.noarch >> nfs-utils-lib-1.1.5-13.el6.x86_64 >> nfs4-acl-tools-0.3.3-8.el6.x86_64 >> nfs-utils-1.2.3-78.el6_10.1.x86_64 >> >> Client: >> CentOS 7 KVM VM running on the server >> sssd-ldap-1.16.2-13.el7_6.5.x86_64 >> python-ldap-2.4.15-2.el7.x86_64 >> openldap-2.4.44-21.el7_6.x86_64 >> nfs4-acl-tools-0.3.3-19.el7.x86_64 >> nfs-utils-1.3.0-0.61.el7.x86_64 >> libnfsidmap-0.25-19.el7.x86_64 >> >> Both machines are fully updated. >> >> Would you like to see any of the myriad of configuration files for >> these applications? Just ask and you shall receive. Please be sure >> to tell me if you want the file from the server or the client hey. >> > > Content of idmapd.conf: Server: [General] #Verbosity = 0 # The following should be set to the local NFSv4 domain name # The default is the host's DNS domain name. #Domain = local.domain.edu Domain = peach.patch.mylan Client: [General] #Verbosity = 0 # The following should be set to the local NFSv4 domain name # The default is the host's DNS domain name. #Domain = local.domain.edu Domain = poppy.patch.mylan Now one more question. The imap daemon is a mail server. How is it that I need a mail server running to make LDAP and NFS work? Doesn't seem to make sense to me. -- _ °v° /(_)\ ^ ^ Mark LaPierre Registered Linux user No #267004 https://linuxcounter.net/ ****

4 5

nobody:nobody
by Mark LaPierre 03 Apr '19

03 Apr '19

Hey Y'all, For the last week or more I've been trying to get NFS and OpenLDAP to play nice with each other. I've pretty much worn the Google machine out trying to find a solution. I've found several that said "Solved" but none of those solutions solved my nobody:nobody problem. In the past I've used NFS in conjunction with NIS to share home directories from my NFS server but I read that NIS is deprecated in favor of LDAP so, being a sucker for new ideas, I decided I would use LDAP too like the big boys do. I think I'm regretting this decision. Now the question: Is there something I need to configure on the client side of the relationship that all the Google wisdom has failed to mention? All the guides/tutorial/etc... talk extensively about configuring the server, many giving conflicting information, but have nothing to say about the client. I've even found a couple that talk about configuring CentOS 6 but contain commands found only in CentOS 7. Makes one go hmmm? Here's the basic details: Server: CentOS 6 openldap-2.4.40-16.el6.i686 openldap-clients-2.4.40-16.el6.x86_64 perl-LDAP-0.40-3.el6.noarch sssd-ldap-1.13.3-60.el6_10.2.x86_64 openldap-2.4.40-16.el6.x86_64 openldap-servers-2.4.40-16.el6.x86_64 python-ldap-2.3.10-1.el6.x86_64 apr-util-ldap-1.3.9-3.el6_0.1.x86_64 smbldap-tools-0.9.6-4.el6.noarch nfs-utils-lib-1.1.5-13.el6.x86_64 nfs4-acl-tools-0.3.3-8.el6.x86_64 nfs-utils-1.2.3-78.el6_10.1.x86_64 Client: CentOS 7 KVM VM running on the server sssd-ldap-1.16.2-13.el7_6.5.x86_64 python-ldap-2.4.15-2.el7.x86_64 openldap-2.4.44-21.el7_6.x86_64 nfs4-acl-tools-0.3.3-19.el7.x86_64 nfs-utils-1.3.0-0.61.el7.x86_64 libnfsidmap-0.25-19.el7.x86_64 Both machines are fully updated. Would you like to see any of the myriad of configuration files for these applications? Just ask and you shall receive. Please be sure to tell me if you want the file from the server or the client hey. -- _ °v° /(_)\ ^ ^ Mark LaPierre Registered Linux user No #267004 https://linuxcounter.net/ ****

2 1

CentOS-announce Digest, Vol 170, Issue 1
by centos-announce-request＠centos.org 02 Apr '19

02 Apr '19

Send CentOS-announce mailing list submissions to centos-announce(a)centos.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.centos.org/mailman/listinfo/centos-announce or, via email, send a message with subject or body 'help' to centos-announce-request(a)centos.org You can reach the person managing the list at centos-announce-owner(a)centos.org When replying, please edit your Subject line so it is more specific than "Re: Contents of CentOS-announce digest..." Today's Topics: 1. Announcing the release of Gluster 6 on CentOS Linux 7 x86_64 (Niels de Vos) 2. Announcing the release of Gluster 6 on CentOS Linux 6 x86_64 (Niels de Vos) 3. CEBA-2019:0689 CentOS 6 tzdata BugFix Update (Johnny Hughes) 4. CESA-2019:0672 Critical CentOS 6 firefox Security Update (Johnny Hughes) 5. CESA-2019:0680 Important CentOS 6 thunderbird Security Update (Johnny Hughes) 6. CESA-2019:0671 Critical CentOS 7 firefox Security Update (Johnny Hughes) 7. CESA-2019:0681 Important CentOS 7 thunderbird Security Update (Johnny Hughes) 8. CESA-2019:0679 Important CentOS 7 libssh2 Security Update (Johnny Hughes) 9. CEBA-2019:0689 CentOS 7 tzdata BugFix Update (Johnny Hughes) ---------------------------------------------------------------------- Message: 1 Date: Thu, 28 Mar 2019 15:48:42 +0100 From: Niels de Vos <ndevos(a)redhat.com> To: centos-announce(a)centos.org Subject: [CentOS-announce] Announcing the release of Gluster 6 on CentOS Linux 7 x86_64 Message-ID: <20190328144842.GD2572(a)ndevos-x270.lan.nixpanic.net> Content-Type: text/plain; charset="us-ascii" I am happy to announce the General Availability of Gluster 6 for CentOS 7 on x86_64. These packages are following the upstream Gluster Community releases, and will receive monthly bugfix updates. Gluster 6 is expected to receive updates until the end of March 2020. The maintanance and release schedule can be found at: https://www.gluster.org/release-schedule/ Users of CentOS 7 can now simply install Gluster 6 with only these two commands: # yum install centos-release-gluster # yum install glusterfs-server The centos-release-gluster package is delivered via CentOS Extras repos. This contains all the metadata and dependency information, needed to install Gluster 6. The actual package that will get installed is centos-release-gluster6. Users of Gluster 4.1 can stay on that release until June 2019. We have a quickstart guide specifically built around the packages are available, it makes for a good introduction to Gluster and will help get you started in just a few simple steps, this quick start is available at https://wiki.centos.org/SpecialInterestGroup/Storage/gluster-Quickstart More details about the packages that the Gluster project provides in the Storage SIG is available in the documentation: https://wiki.centos.org/SpecialInterestGroup/Storage/Gluster The centos-release-gluster* repositories offer additional packages that enhance the usability of Gluster itself. Utilities and tools that were working with previous versions of Gluster are expected to stay working fine. If there are any problems, or requests for additional tools and applications to be provided, just send us an email with your suggestions. The current list of packages that is (planned to become) available can be found here: https://wiki.centos.org/SpecialInterestGroup/Storage/Gluster/Ecosystem-pkgs We welcome all feedback, comments and contributions. You can get in touch with the CentOS Storage SIG on the centos-devel mailing list (https://lists.centos.org ) and with the Gluster developer and user communities at https://www.gluster.org/mailman/listinfo , we are also available on irc at #gluster on irc.freenode.net, and on twitter at @gluster . Cheers, Niels de Vos Storage SIG member & Gluster maintainer

1 0

git.centos.org migration, please read
by Fabian Arrotin 02 Apr '19

02 Apr '19

As pre-announced a long time ago (see https://lists.centos.org/pipermail/centos-devel/2018-October/016997.html) , we'll migrate git.centos.org to a new host/platform (pagure/repospanner) The current migration is planned for : April 8th (more details later about the exact hour, as we need to have acknowledgement from all involved people). Instead of writing a long email, we instead decided to put focus on a dedicated page, that will , after migration, replace the current one. - current one : https://wiki.centos.org/Sources - new one : https://wiki.centos.org/Sources_new After migration, we'll rename/swap both pages, to reflect the changes that will go live next monday. As a reminder : we had https://git.stg.centos.org and https://src.stg.fedoraproject.org in "sync" since October, replicating to each other instance. We also got good feedback from CentOS contributors who started to use it to test the new features, including the automatic ACL for protected branches, and some pkgs from CentOS distro were even built through that staging instance , to validate that it was working the way it was designed. So please read that wiki page (https://wiki.centos.org/Sources_new) and we can also add/correct things in that page, based on future feedback. WRT existing repositories : they'll all be imported (already validated) but if you had access (RWC) to a specific project, you'll have *first* to login with your ACO account, and then ask to be added to the ACL, as well as changing the "git remote" url, to point to ssh (all pushes are going through ssh, as previous gitblit/git.centos.org allowed https pushes) PS: while the date is normally April 8th, if there is a chance that we'd need to change that date, we'll post an update in this thread PS2 : Fedora infra is in "freeze" mode , meaning that during our migration, we'll start with only the CentOS branches, and Fedora will import their repositories/branches in the existing repospanner cluster later, and so the Fedora/EPEL branches will then automatically appear on https://git.centos.org -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 56BEC54E | twitter: @arrfab

1 0

udev rename NIC failed
by wuzhouhui 01 Apr '19

01 Apr '19

Hi, Sometimes, I found one of my Mellanox NIC renamed to rename6, instead of eth1. The right names of NICs in my system should be: eth0 Mellanox NIC eth1 Mellanox NIC eth2 Intel NIC eth3 Intel NIC eth4 Intel NIC eth5 Intel NIC eth0 and eth1 will combined as bond1 with mode 4. However, the current names are: eth0 Mellanox NIC rename6 Mellanox NIC eth1 Intel NIC eth2 Intel NIC eth4 Intel NIC eth5 Intel NIC And bond1 still consist of eth0 and eth1, but eth1 is Intel NIC, instead of Mellanox NIC. Following is selected log from /var/log/messages: ... kernel: [ 23.098148] i40e: Intel(R) 40-10 Gigabit Ethernet Connection Network Driver - version 2.2.4 kernel: [ 23.098554] i40e: Copyright(c) 2013 - 2017 Intel Corporation. kernel: [ 23.114270] i40e 0000:1a:00.0: fw 3.1.57069 api 1.5 nvm 3.33 0x80000f09 255.65535.255 kernel: [ 23.118320] i40e 0000:1a:00.0: MAC address: 28:41:c6:fb:c3:a2 kernel: [ 23.128007] i40e 0000:1a:00.0: MSI-X vector limit reached, attempting to redistribute vectors kernel: [ 23.133699] i40e 0000:1a:00.0: Added LAN device PF0 bus=0x1a dev=0x00 func=0x00 kernel: [ 23.134414] i40e 0000:1a:00.0: Features: PF-id[0] VFs: 32 VSIs: 34 QP: 56 RSS FD_ATR FD_SB NTUPLE CloudF DCB VxLAN NVGRE PTP VEPA kernel: [ 23.148085] i40e 0000:1a:00.1: fw 3.1.57069 api 1.5 nvm 3.33 0x80000f09 255.65535.255 kernel: [ 23.151729] i40e 0000:1a:00.1: MAC address: 28:41:c6:fb:c3:a3 kernel: [ 23.160694] i40e 0000:1a:00.1: MSI-X vector limit reached, attempting to redistribute vectors kernel: [ 23.166232] i40e 0000:1a:00.1: Added LAN device PF1 bus=0x1a dev=0x00 func=0x01 kernel: [ 23.167280] i40e 0000:1a:00.1: Features: PF-id[1] VFs: 32 VSIs: 34 QP: 56 RSS FD_ATR FD_SB NTUPLE CloudF DCB VxLAN NVGRE PTP VEPA kernel: [ 23.185771] i40e 0000:1a:00.2: fw 3.1.57069 api 1.5 nvm 3.33 0x80000f09 255.65535.255 kernel: [ 23.193232] i40e 0000:1a:00.2: MAC address: 28:41:c6:fb:c3:a4 kernel: [ 23.207420] i40e 0000:1a:00.2: MSI-X vector limit reached, attempting to redistribute vectors kernel: [ 23.217474] i40e 0000:1a:00.2: Added LAN device PF2 bus=0x1a dev=0x00 func=0x02 kernel: [ 23.219339] i40e 0000:1a:00.2: Features: PF-id[2] VFs: 32 VSIs: 34 QP: 56 RSS FD_ATR FD_SB NTUPLE CloudF DCB VxLAN NVGRE PTP VEPA kernel: [ 23.237958] i40e 0000:1a:00.3: fw 3.1.57069 api 1.5 nvm 3.33 0x80000f09 255.65535.255 kernel: [ 23.242039] i40e 0000:1a:00.3: MAC address: 28:41:c6:fb:c3:a5 kernel: [ 23.258645] i40e 0000:1a:00.3: MSI-X vector limit reached, attempting to redistribute vectors kernel: [ 23.270395] i40e 0000:1a:00.3: Added LAN device PF3 bus=0x1a dev=0x00 func=0x03 kernel: [ 23.271911] i40e 0000:1a:00.3: Features: PF-id[3] VFs: 32 VSIs: 34 QP: 56 RSS FD_ATR FD_SB NTUPLE CloudF DCB VxLAN NVGRE PTP ... kernel: [ 250.279739] Compat-mlnx-ofed backport release: f8de107 kernel: [ 250.280006] Backport based on mlnx_ofed/mlnx-ofa_kernel-4.0.git f8de107 kernel: [ 250.280261] compat.git: mlnx_ofed/mlnx-ofa_kernel-4.0.git kernel: [ 250.287865] mlx5_core 0000:3b:00.0: firmware version: 14.23.1020 kernel: [ 250.293492] tun: Universal TUN/TAP device driver, 1.6 kernel: [ 250.293731] tun: (C) 1999-2004 Max Krasnyansky <maxk(a)qualcomm.com> kernel: [ 250.360407] nbd: registered device at major 43 kernel: [ 250.367659] nf_conntrack version 0.5.0 (65536 buckets, 262144 max) kernel: [ 250.373103] VFIO - User Level meta-driver version: 0.3 kernel: [ 250.455352] EXT4-fs (sda2): re-mounted. Opts: (null) kernel: [ 250.489486] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) kernel: [ 251.202430] (0000:3b:00.0): E-Switch: Total vports 9, per vport: max uc(1024) max mc(16384) kernel: [ 251.343924] mlx5_core 0000:3b:00.1: firmware version: 14.23.1020 kernel: [ 252.273017] (0000:3b:00.1): E-Switch: Total vports 9, per vport: max uc(1024) max mc(16384) kernel: [ 252.411436] mlx5_core 0000:3b:00.0: MLX5E: StrdRq(1) RqSz(8) StrdSz(64) RxCqeCmprss(0) kernel: [ 252.575886] mlx5_core 0000:3b:00.1: MLX5E: StrdRq(1) RqSz(8) StrdSz(64) RxCqeCmprss(0) kernel: [ 252.814797] mlx5_ib: Mellanox Connect-IB Infiniband driver v4.2-1.2.0 kernel: [ 343.507623] Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011) kernel: [ 343.508800] bonding: bond1 is being created... kernel: [ 343.525710] bond1: Setting MII monitoring interval to 100 kernel: [ 343.526101] bond1: Setting xmit hash policy to layer2+3 (2) kernel: [ 343.528088] IPv6: ADDRCONF(NETDEV_UP): bond1: link is not ready kernel: [ 343.543330] bond1: Adding slave eth0 kernel: [ 343.834246] mlx5_core 0000:3b:00.0 eth0: mlx5e_update_carrier:153: Link up kernel: [ 343.837195] bond1: Enslaving eth0 as a backup interface with an up link kernel: [ 343.852012] bond1: Adding slave eth1 kernel: [ 343.852264] i40e 0000:1a:00.1 eth1: set new mac address 98:03:9b:83:cd:5e kernel: [ 343.860085] bond1: Enslaving eth1 as a backup interface with a down link ... udevd-work[15328]: error changing netif name 'eth1' to 'eth3': Device or resource busy .... It seems that udevd failed to rename eth1 to eth3, because eth1 has been enslaved by bond1. Does anyone know how to handle this problem? i40e: 2.2.4 CentOS: 6.3 mlx5_core: 4.2 Thanks.

2 1

Getting slapd under CentOS 6 to log connections, etc.
by Robert Heller 31 Mar '19

31 Mar '19

I am running the stock OpenLDAP-servers on a CentOS 6 system. Everything is working just fine, but I am trying to debug connections from a Ubuntu (18.04) system and want to turn on logging in slapd, but although I can get slapd to create a log file, it never actually writes anything. I have these two lines in /etc/openldap/slapd.d/cn=config.ldif: olcLogFile: /var/log/slapd/log olcLogLevel: conns BER config ACL stats none And although /var/log/slapd/log gets created, nothing is ever written to it. What am I missing? -- Robert Heller -- 978-544-6933 Deepwoods Software -- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services heller(a)deepsoft.com -- Webhosting Services

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss