That sounds like old-school:
Under traditional "Dual-stack" the intended procedure was indeed first to try
IPv6, and only when it fails, THAN to try legacy Ipv4.
It was thought that (network) administrators would take their responsibility
seriously ;-(
Last February, @FOSDEM-RTC-devroom, I was i
On Sun, Apr 9, 2017 at 10:49 PM, Samuel Sieb wrote:
> On 04/09/2017 07:25 PM, JD wrote:
>>
>> On 04/09/2017 06:02 PM, Samuel Sieb wrote:
>>>
>>> ssh user_foo@1.2.3.4 "pgrep -f 'master_app' | wc -l" 2> stderr.log
>>>
>>> would write any errors to the file "stderr.log" on the local box.
>>
>> Those
On 09/04/17 05:50 PM, Ian Pilcher wrote:
> I'm not sure when this started, but I am unable to switch away from my
> X VT (usually VT 1) to a text VT.
>
> Actually, blind-typing shows that I am actually able to switch to the
> text VT, but nothing shows up; I'm left looking at a "frozen" version of
On 04/09/2017 11:46 PM, Frédéric Bron wrote:
First try and apprently maybe a first error (write:errno=104):
OK, errno 104 is ECONNRESET (Connection reset by peer). That might be
because some firewall or router in between your system and the server is
sending a TCP reset packet to disrupt th
On 04/09/2017 07:25 PM, JD wrote:
ssh user_foo@1.2.3.4 "pgrep -f 'master_app' | wc -l" 2> stderr.log
would write any errors to the file "stderr.log" on the local box.
Those stderr messages would be coming from wc and NOT from ssh.
The OP's command should be
ssh user_foo@1.2.3.4 2> stderr.log
On 04/10/2017 05:56 AM, bruce wrote:
So if I get what you guys have said...
ssh crawl_user@1.2.3.4 2>&1 pgrep -f 'master_client' | wc -l
would work with the >> 2>&1 << writing the stderr to the stdout for the ssh
For curiosity's sake, let's look at how the shell parses and executes
that
On 04/10/2017 10:32 AM, Gordon Messmer wrote:
On 04/09/2017 07:25 PM, JD wrote:
ssh user_foo@1.2.3.4 "pgrep -f 'master_app' | wc -l" 2> stderr.log
would write any errors to the file "stderr.log" on the local box.
Those stderr messages would be coming from wc and NOT from ssh.
The OP's comm
I've go so many messages like this from the most recent firefox that it is
unusable. I have tried removing all extensions, etc. and disabling hardware
acceleration, but without any improvement. Therefor I downgraded to
firefox-49.0-2.fc25, which seems to be working OK. The problem appears to
I had some trouble with the KDE apper program and (in the process of fixing it)
disabled the KDE applet in the system tray that manages it. It's not clear how
to get the applet back. Can anyone tell me on how to re-enable it?
BTW: The problem with apper is a bug in PackageKit (apper's backend)
On 04/10/2017 11:30 AM, JD wrote:
On 04/10/2017 10:32 AM, Gordon Messmer wrote:
On 04/09/2017 07:25 PM, JD wrote:
ssh user_foo@1.2.3.4 "pgrep -f 'master_app' | wc -l" 2> stderr.log
Those stderr messages would be coming from wc and NOT from ssh.
The OP's command should be
ssh user_foo@1.2.3.4 2
On 04/10/2017 12:43 PM, Jonathan Ryshpan wrote:
I had some trouble with the KDE apper program and (in the process of
fixing it) disabled the KDE applet in the system tray that manages it.
It's not clear how to get the applet back. Can anyone tell me on how to
re-enable it?
I don't use KDE, so t
On 04/10/2017 12:46 PM, Gordon Messmer wrote:
I did understand. It doesn't matter if 2>file appears before the ssh
arguments, or at the end. In both cases, ssh's stderr will be written
to a local file. It is incorrect to say that the former example would
redirect wc's stderr, and not ssh.
T
On 04/10/2017 01:01 PM, Joe Zeff wrote:
On 04/10/2017 12:46 PM, Gordon Messmer wrote:
I did understand. It doesn't matter if 2>file appears before the ssh
arguments, or at the end. In both cases, ssh's stderr will be written
to a local file. It is incorrect to say that the former example wou
On 04/10/2017 12:46 PM, Gordon Messmer wrote:
> On 04/10/2017 11:30 AM, JD wrote:
>> On 04/10/2017 10:32 AM, Gordon Messmer wrote:
>>> On 04/09/2017 07:25 PM, JD wrote:
> ssh user_foo@1.2.3.4 "pgrep -f 'master_app' | wc -l" 2> stderr.log
Those stderr messages would be coming from wc and NO
On Mon, Apr 10, 2017 at 01:29:59PM -0700, Rick Stevens wrote:
> On 04/10/2017 12:46 PM, Gordon Messmer wrote:
...
>
> That's correct. In both examples, the commands inside the double quotes
> and only what's inside the quotes are what's executed on the remote
> system. Everything else is executed
On Mon, 10 Apr 2017 11:41:01 -0700
Jonathan Ryshpan wrote:
> I've go so many messages like this from the most recent firefox that
> it is unusable. I have tried removing all extensions, etc. and
> disabling hardware acceleration, but without any improvement.
> Therefor I downgraded to firefox-49
On 04/10/2017 01:42 PM, Jon LaBadie wrote:
> On Mon, Apr 10, 2017 at 01:29:59PM -0700, Rick Stevens wrote:
>> On 04/10/2017 12:46 PM, Gordon Messmer wrote:
> ...
>>
>> That's correct. In both examples, the commands inside the double quotes
>> and only what's inside the quotes are what's executed on
On 04/10/2017 01:56 PM, Rick Stevens wrote:
Might as well be complete:
2>stderr.log sshuser_foo@1.2.3.4 "pgrep -f 'master_app' | wc -l"
is also equivalent
Uhm, dunno about that one as you'd be redirecting stderr of the shell
itself--not the stderr of the ssh command ONLY. I also don't
On 04/10/2017 01:18 PM, Gordon Messmer wrote:
In that case, ssh and wc's stderr will be written to stderr.log, just
the same as the other two formats.
ICBW, but I was under the impression that the OP wanted to capture any
error output from ssh itself and wasn't concerned with errors at the
when i rebuild the src.rpm with my .rpmrc file i became the error "illegal
instruction", when i create the rpm without the .rpmrc file it works perfectly!
other builds (pure-ftpd, mpd, mpdscribble, samba, openssl) works with my rpmrc
file, but why it breaks httpd-* and mod_* files? maybe the prob
On 04/10/2017 02:23 PM, Joe Zeff wrote:
ICBW, but I was under the impression that the OP wanted to capture any
error output from ssh itself and wasn't concerned with errors at the
other end.
It's difficult to separate the two. You'd have to ensure that stderr on
the remote end was either wri
On Fri, Apr 07, 2017 at 11:25:03PM +0200, Zoltan Hoppar wrote:
> Technically would it be possible to gather under a single "Fedora Store"
> page/hub those companies that has licensed merchandise? I mean not to build
Yes - good idea. I don't think there's a problem with it for authorized
merchandis
Im having an issue with setting static routes that are persistent.
FOllowing the Fedora documention for 25:
https://docs.fedoraproject.org/en-US/Fedora/25/html/Networking_Guide/sec-Configuring_Static_Routes_in_ifcfg_files.html
After some mixup, I set one static route in NetworkManager for my main
> Either way, I think the possibility of an IPv6 problem is worth
> investigating. Close all of your applications, then open two terminals. In
> one, run:
>
> $ sudo tcpdump -nn port 443
>
> In the other, run the same s_client command to connect to the python docs
> server. Send us the output of
On 04/11/17 11:56, Frédéric Bron wrote:
> apparently, although I ticked "IPv4 required for this connexion", IPv6 is
> used.
Just a quick note on the meaning of that check box.
It means that in order for that interface to be marked as UP it needs to
have an IPv4 address. That's all it means. I
On 04/11/17 00:25, Gordon Messmer wrote:
> On 04/09/2017 11:46 PM, Frédéric Bron wrote:
>> First try and apprently maybe a first error (write:errno=104):
>
>
> OK, errno 104 is ECONNRESET (Connection reset by peer). That might be
> because some firewall or router in between your system and the ser
On 04/10/2017 08:56 PM, Frédéric Bron wrote:
# tcpdump -nn port 443
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp62s0u1u4, link-type EN10MB (Ethernet), capture size 262144 bytes
05:38:34.536393 IP6 2001:41d0:fe0b:8000:9a64:ff80:35b8:7d03.60038 >
2a04
On 04/10/2017 09:30 PM, Ed Greshko wrote:
May I suggest that IP address be used instead of the host name?
I specifically wanted to use the hostname because I assumed that if this
were an IPv6 vs IPv4 sort of problem, we'd see that difference in
successful and unsuccessful connections. We di
> It would be useful to disable IPv6 for this connection and try again.
So applied the command proposed by Ed as root:
$ echo 1 > /proc/sys/net/ipv6/conf/(name of interface)/disable_ipv6
and now I never have any error, the page always shows in firefox,
konqueror or chrome.
Also openssl s_client -
On 04/10/2017 11:09 PM, Frédéric Bron wrote:
It would be useful to disable IPv6 for this connection and try again.
So applied the command proposed by Ed as root:
$ echo 1 > /proc/sys/net/ipv6/conf/(name of interface)/disable_ipv6
It might be simpler to disable IPv6 on one connection. From you
On 04/11/17 14:34, Gordon Messmer wrote:
> Probably your ISP, given the packet sequence you saw. Unless someone
> else can replicate the problem with that IP address. I might try
> tomorrow, but openssl's s_client doesn't take ipv6 addresses as
> arguments, so testing is more involved.
Yes, op
>> In your opinion, is this an issue with fedora or with my ISP (which is
>> OVH)?
>
> Probably your ISP, given the packet sequence you saw. Unless someone else
> can replicate the problem with that IP address. I might try tomorrow, but
> openssl's s_client doesn't take ipv6 addresses as argument
On 04/11/17 14:37, Frédéric Bron wrote:
>>> In your opinion, is this an issue with fedora or with my ISP (which is
>>> OVH)?
>> Probably your ISP, given the packet sequence you saw. Unless someone else
>> can replicate the problem with that IP address. I might try tomorrow, but
>> openssl's s_cli
33 matches
Mail list logo
