[CentOS] xinetd custom service - perl - remote address
Hi all,
I can't believe that I can't find the answer to this one. I have a perl script
which is called by xinetd.
I want that perl script to be able to detect the remote IP address of the
caller.
I presumed that it would be an environment variable but I could be wrong. I've
found reference to the ENV and PASSENV arguments for xinetd.conf but no
examples, and no indication of what auguments to use.
In my script I have the following code:
foreach (keys %ENV) { print "$_=$ENV{$_}\n";}
but the only line I get back is:
XINETD_LANG=en_US
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] xinetd custom service - perl - remote address
On Thu, May 28, 2020 at 04:46:34PM +0100, Gary Stainburn wrote:
>
> Hi all,
>
> I can't believe that I can't find the answer to this one. I have a
> perl script which is called by xinetd.
>
> I want that perl script to be able to detect the remote IP address
> of the caller.
>
> I presumed that it would be an environment variable but I could be
> wrong. I've found reference to the ENV and PASSENV arguments for
> xinetd.conf but no examples, and no indication of what auguments to
> use.
>
> In my script I have the following code:
>
> foreach (keys %ENV) { print "$_=$ENV{$_}\n";}
>
>
> but the only line I get back is:
>
> XINETD_LANG=en_US
I don't believe that xinetd tells the underlying processes anything
about IPs, since xinetd handles the network connection and as far as
the process is concerned, it's just filehandles.
--
Jonathan Billings
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] xinetd custom service - perl - remote address
> Hi all,
>
> I can't believe that I can't find the answer to this one. I have a perl
> script which is called by xinetd.
>
> I want that perl script to be able to detect the remote IP address of the
> caller.
>
> I presumed that it would be an environment variable but I could be wrong.
> I've found reference to the ENV and PASSENV arguments for xinetd.conf but
> no examples, and no indication of what auguments to use.
>
> In my script I have the following code:
>
> foreach (keys %ENV) { print "$_=$ENV{$_}\n";}
>
>
> but the only line I get back is:
The variable you may want is REMOTE_HOST, at least that's what I see on a
host of mine.
Regards,
Simon
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] xinetd custom service - perl - remote address
On 5/28/2020 8:55 AM, Jonathan Billings wrote: I don't believe that xinetd tells the underlying processes anything about IPs, since xinetd handles the network connection and as far as the process is concerned, it's just filehandles. Isn't the filehandle just a socket? So can't you use Perl's socket API to recover the connection information? So the next problem is to find something that wraps an existing filehandle in a Perl socket object. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] xinetd custom service - perl - remote address
In article <202005281646.34790.gary.stainb...@ringways.co.uk>,
Gary Stainburn wrote:
> Hi all,
>
> I can't believe that I can't find the answer to this one. I have a perl
> script which is called by xinetd.
>
> I want that perl script to be able to detect the remote IP address of the
> caller.
>
> I presumed that it would be an environment variable but I could be wrong.
> I've found reference to the ENV and PASSENV
> arguments for xinetd.conf but no examples, and no indication of what
> auguments to use.
>
> In my script I have the following code:
>
> foreach (keys %ENV) { print "$_=$ENV{$_}\n";}
>
>
> but the only line I get back is:
>
> XINETD_LANG=en_US
Works for me. Here are my details:
1. /usr/local/bin/args:
#!/usr/bin/perl
$i=1;
while(defined($_ = shift)) {
printf "ARGV[%d]=\"%s\"\n",$i++,$_;
}
foreach $env (keys %ENV) {
printf "ENV{%s}=\"%s\"\n",$env,$ENV{$env};
}
2. /etc/xinetd.d/args:
service args
{
disable = no
port = 54321
type = UNLISTED
socket_type = stream
wait= no
user= root
server = /usr/local/bin/args
server_args = --test
log_on_failure += USERID
}
3. Results of telnet 127.0.0.1 54321:
# telnet 127.0.0.1 54321
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
ARGV[1]="--test"
ENV{CONSOLE}="/dev/console"
ENV{PREVLEVEL}="N"
ENV{SELINUX_INIT}="YES"
ENV{LC_COLLATE}="en_US"
ENV{RUNLEVEL}="3"
ENV{LC_ALL}="en_US"
ENV{previous}="N"
ENV{LC_NUMERIC}="en_US"
ENV{PWD}="/"
ENV{LC_TIME}="en_US"
ENV{LANG}="en_US"
ENV{LC_MESSAGES}="en_US"
ENV{runlevel}="3"
ENV{INIT_VERSION}="sysvinit-2.86"
ENV{SHLVL}="3"
ENV{LC_MONETARY}="en_US"
ENV{_}="/usr/sbin/xinetd"
ENV{PATH}="/sbin:/usr/sbin:/bin:/usr/bin"
ENV{vga}="773"
ENV{REMOTE_HOST}="127.0.0.1"
ENV{TERM}="linux"
Connection closed by foreign host.
Notice the value of ENV{REMOTE_HOST}
Cheers
Tony
--
Tony Mountifield
Work: t...@softins.co.uk - http://www.softins.co.uk
Play: t...@mountifield.org - http://tony.mountifield.org
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] xinetd custom service - perl - remote address
On Thursday 28 May 2020 18:12:55 Tony Mountifield wrote: > In article <202005281646.34790.gary.stainb...@ringways.co.uk>, > Works for me. Here are my details: > Thanks for this Tony. This is exactly what I had expected to happen. I subsitiuted your server for mine and got exactly the same results. The problem was not my server, but the client (Powershell on Win10) losing half of the data I returned. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] Recover from an fsck failure
This is CentOS-6x. I have cloned the HDD of a CentOS-6 system. I booted a host with that drive and received the following error: checking filesystems /dev/mapper/vg_voinet01-lv_root: clean, 128491/4096000 files, 1554114/16304000 blocks /dev/sda1: clean, 47/120016 files, 80115/512000 blocks /dev/mapper/vg_voinet01-lv_home: clean, 7429/204800 files, 90039/819200 blocks /dev/mapper/vg_voinet01-LogVol04: clean, 770219/2048 files, 34881086/8102000 blocks fsck.ext4: Bad magic number in super-block while trying to open /dev/mapper/vg_voinet01-lv_log /dev/mapper/vg_voinet01-lv_log The superblock could not be read or does not describe a correct ext2 filesystem. If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsk -b 8193 /dev/mapper/vg_voinet-lv_spool: clean, 372/614400 files, 171186/2457600 blocks *** An error occurred during the file system check. *** Dropping you to a shell; the system will reboot *** when you leave the shell. Give root password for maintenance (or type Control-D to continue): I ran mke2fs to locate the backup superblocks: mke2fs -n /dev/mapper/vg_voinet01-lv_log . . . Superblock backups stored on blocks: 32768, 90304, 163840, 229376, 294912, 819200, 884736, 1605632 and ran: e2fsck -b 32768 /dev/mapper/vg_voinet01-lv_log The superblock could not be read or does not describe a correct ext2 The same thing happened for the next backup superblock addrees. And all the rest reported an invalid argument error from e2fsck. Is this recoverable? How? -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail Do NOT open attachments nor follow links sent by e-Mail James B. Byrnemailto:byrn...@harte-lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Recover from an fsck failure
> > I ran mke2fs to locate the backup superblocks: > > mke2fs -n /dev/mapper/vg_voinet01-lv_log That will only tell you what mke2fs would do on that machine. I don't know if it will be the same on every machine. You should probably run dumpe2fs /dev/mapper/vg_voinet01-lv_log | grep superblock If that doesn't work, then I suspect it's not recoverable using fsck. If you are sure that it is an ext2/3/4 filesystem on there, then you can try using something like TestDisk to scan for partitions. It should be in epel. P. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Recover from an fsck failure
On 5/28/20 1:33 PM, James B. Byrne via CentOS wrote: /dev/mapper/vg_voinet01-lv_log The superblock could not be read or does not describe a correct ext2 filesystem. If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsk -b 8193 What output do you get from: file -s /dev/mapper/vg_voinet01-lv_log lsblk -f /dev/mapper/vg_voinet01-lv_log -- Bob Nichols "NOSPAM" is really part of my email address. Do NOT delete it. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] network disconnection after several hours
I will check with firewall-cmd. Regarding hardware problem I have doubt as we use VMWare (but I keep in a corner of my mind).At this moment, we have compiled kernel and have installed it and have tried 4 restore passed.We need to do more tests and understand why 4 restores passed. Thanks Thomas Poty Le jeudi 28 mai 2020 à 23:58:22 UTC+2, hw a écrit : On Tuesday, May 26, 2020 2:42:13 PM CEST Thomas Poty via CentOS wrote: > Hi,We have tried : > - with and without NetworkManager-config-server- with and without > NetworkManagerbut result is still the same : we get disconnection :-/ We > will try with the last kernel. > anybody has a track to explore ? > Thanks > Have you enabled logging with firewall-cmd to see if there are packets being dropped while the dump is being restored? Besides that, one of the first things I'd try is changing out the network card, replace the network cable and use a different port on the switch. Keep in mind that two machines are involved. Even stupid network cables can "switch" between working and non-working for no reason at all like you wouldn't believe ... until you plug them into a PoE switch by mistake after which they suddenly no longer work at all. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
