.tmp-unverified-download-quarantine

classic Classic list List threaded Threaded
37 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: .tmp-unverified-download-quarantine

n952162
On 2020-01-14 00:16, Mick wrote:

> On Monday, 13 January 2020 22:40:14 GMT Neil Bothwick wrote:
>> On Mon, 13 Jan 2020 11:15:31 +0000, Mick wrote:
>>> According to my emerge --info output I have sandbox, usersandbox and
>>> userpriv, all set.  The owner of my portage directory and all files
>>> therein is root:root.  Should the ownership be portage:portage?  What
>>> is the default?
>> As it happens, I switched a machine from rsync to git syncing last night,
>> so started with a new tree. Everything is root:root. That implies that
>> portage does not drop permissions for the sync, otherwise it wouldn't be
>> able to write to the tree. And ps confirms that with an rsync sync, rsync
>> is running as root.
> Thanks Neil, this this leaves me mildly confused as to what the gentoo-default
> ownership of portage tree is/should be.  Until I hear differently I'll leave
> my old installations as portage:portage and the latest as root:root.
>
It sounds to me like the repository is broken - having ownership as root
seems to be slightly more entropy than portage and could have happened
as a unintended consequence of some uncarefully completed operation.

Is this the proper list to be on?


Reply | Threaded
Open this post in threaded view
|

Re: .tmp-unverified-download-quarantine

Neil Bothwick
On Tue, 14 Jan 2020 09:04:13 +0100, n952162 wrote:

> It sounds to me like the repository is broken - having ownership as root
> seems to be slightly more entropy than portage and could have happened
> as a unintended consequence of some uncarefully completed operation.

If the repository was broken, it would be affecting a lot more people
than just you.

Have you tried completely removing your portage tree and reinstating it
with webrsync?
 
> Is this the proper list to be on?

It's the Gentoo User list, which seems to fit.


--
Neil Bothwick

If ignorance is bliss, why aren't more people happy?

attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: .tmp-unverified-download-quarantine

n952162
On 2020-01-14 09:44, Neil Bothwick wrote:

> On Tue, 14 Jan 2020 09:04:13 +0100, n952162 wrote:
>
>> It sounds to me like the repository is broken - having ownership as root
>> seems to be slightly more entropy than portage and could have happened
>> as a unintended consequence of some uncarefully completed operation.
> If the repository was broken, it would be affecting a lot more people
> than just you.
>
> Have you tried completely removing your portage tree and reinstating it
> with webrsync?


This is a fresh install from a minimal cd image.  I'm starting out with
mkfs.  I've tried that 3 times, twice using a stage 3 from 2020/01/08
and once using a stage 3 from 2020/01/12.

Thus, in answer to your question, yes, I've always removed the portage
tree (and everything else).

I've always used emerge --sync rather than webrsync because I always
like to use the smallest hammer possible.  But if you say I should use
webrsync rather than emerge --sync, I have no other hint.



>
>> Is this the proper list to be on?
> It's the Gentoo User list, which seems to fit.
>
>


Reply | Threaded
Open this post in threaded view
|

Re: .tmp-unverified-download-quarantine

Neil Bothwick
On Tue, 14 Jan 2020 10:37:24 +0100, n952162 wrote:

> > Have you tried completely removing your portage tree and reinstating
> > it with webrsync?  

> I've always used emerge --sync rather than webrsync because I always
> like to use the smallest hammer possible.  But if you say I should use
> webrsync rather than emerge --sync, I have no other hint.

It's certainly worth trying webrsync, if anything else, it's faster for a
full tree.

I prefer to use the largest hammer and let the tool do the work for me ;-)


--
Neil Bothwick

SCSI: System Can't See It

attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: .tmp-unverified-download-quarantine

Peter Humphrey-3
In reply to this post by n952162
On Tuesday, 14 January 2020 09:37:24 GMT n952162 wrote:

> On 2020-01-14 09:44, Neil Bothwick wrote:
> > On Tue, 14 Jan 2020 09:04:13 +0100, n952162 wrote:
> >> It sounds to me like the repository is broken - having ownership as root
> >> seems to be slightly more entropy than portage and could have happened
> >> as a unintended consequence of some uncarefully completed operation.
> >
> > If the repository was broken, it would be affecting a lot more people
> > than just you.
> >
> > Have you tried completely removing your portage tree and reinstating it
> > with webrsync?
>
> This is a fresh install from a minimal cd image.  I'm starting out with
> mkfs.  I've tried that 3 times, twice using a stage 3 from 2020/01/08
> and once using a stage 3 from 2020/01/12.

Er...you aren't running out of disk space, are you (either physical space or
inodes)? Don't forget /tmp and /var/tmp. And what result did 'emerge --sync'
return? Specifically, did you see a 'Sync completed' message? Have you watched
/usr/bin/top status lines while syncing?

And have you actually tried emerge-webrsync?

--
Regards,
Peter.




Reply | Threaded
Open this post in threaded view
|

Re: .tmp-unverified-download-quarantine

n952162
On 2020-01-14 11:10, Peter Humphrey wrote:

> On Tuesday, 14 January 2020 09:37:24 GMT n952162 wrote:
>> On 2020-01-14 09:44, Neil Bothwick wrote:
>>> On Tue, 14 Jan 2020 09:04:13 +0100, n952162 wrote:
>>>> It sounds to me like the repository is broken - having ownership as root
>>>> seems to be slightly more entropy than portage and could have happened
>>>> as a unintended consequence of some uncarefully completed operation.
>>> If the repository was broken, it would be affecting a lot more people
>>> than just you.
>>>
>>> Have you tried completely removing your portage tree and reinstating it
>>> with webrsync?
>> This is a fresh install from a minimal cd image.  I'm starting out with
>> mkfs.  I've tried that 3 times, twice using a stage 3 from 2020/01/08
>> and once using a stage 3 from 2020/01/12.
> Er...you aren't running out of disk space, are you (either physical space or
> inodes)? Don't forget /tmp and /var/tmp. And what result did 'emerge --sync'
> return? Specifically, did you see a 'Sync completed' message? Have you watched
> /usr/bin/top status lines while syncing?
>
> And have you actually tried emerge-webrsync?
>

'emerge --sync' gave me status 1 and before that, the error about the
manifest:


Number of files: 158,236 (reg: 131,524, dir: 26,712)
Number of created files: 158,235 (reg: 131,524, dir: 26,711)
Number of deleted files: 0
Number of regular files transferred: 131,524
Total file size: 208.96M bytes
Total transferred file size: 208.96M bytes
Literal data: 208.96M bytes
Matched data: 0 bytes
File list size: 3.90M
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 2.71M
Total bytes received: 218.79M

sent 2.71M bytes  received 218.79M bytes  56.02K bytes/sec
total size is 208.96M  speedup is 0.94
  * Manifest timestamp: 2020-01-12 18:38:55 UTC
  * Valid OpenPGP signature found:
  * - primary key: DCD05B71EAB94199527F44ACDB6B8C1F96D8BF6D
  * - subkey: E1D6ABB63BFCFB4BA02FDF1CEC590EEAC9189250
  * - timestamp: 2020-01-12 18:38:55 UTC
  * Verifying /var/db/repos/gentoo/.tmp-unverified-download-quarantine
...!!! Manifest v>
Manifest mismatch for media-plugins/Manifest.gz
   __size__: expected: 48363, have: 48349


Inodes?  That's an interesting thought.  Not sure how I'd check that ...
I'll redirect the output into a file next time.

What would I look for in the top(1) status lines (the lines at the top
before the process table?)?

With emerge-webrsync do you mean webrsync or is there some additional
facility?



Reply | Threaded
Open this post in threaded view
|

Re: .tmp-unverified-download-quarantine

Dale-46
n952162 wrote:

> On 2020-01-14 11:10, Peter Humphrey wrote:
>> On Tuesday, 14 January 2020 09:37:24 GMT n952162 wrote:
>>> On 2020-01-14 09:44, Neil Bothwick wrote:
>>>> On Tue, 14 Jan 2020 09:04:13 +0100, n952162 wrote:
>>>>> It sounds to me like the repository is broken - having ownership
>>>>> as root
>>>>> seems to be slightly more entropy than portage and could have
>>>>> happened
>>>>> as a unintended consequence of some uncarefully completed operation.
>>>> If the repository was broken, it would be affecting a lot more people
>>>> than just you.
>>>>
>>>> Have you tried completely removing your portage tree and
>>>> reinstating it
>>>> with webrsync?
>>> This is a fresh install from a minimal cd image.  I'm starting out with
>>> mkfs.  I've tried that 3 times, twice using a stage 3 from 2020/01/08
>>> and once using a stage 3 from 2020/01/12.
>> Er...you aren't running out of disk space, are you (either physical
>> space or
>> inodes)? Don't forget /tmp and /var/tmp. And what result did 'emerge
>> --sync'
>> return? Specifically, did you see a 'Sync completed' message? Have
>> you watched
>> /usr/bin/top status lines while syncing?
>>
>> And have you actually tried emerge-webrsync?
>>
>
> 'emerge --sync' gave me status 1 and before that, the error about the
> manifest:
>
>
> Number of files: 158,236 (reg: 131,524, dir: 26,712)
> Number of created files: 158,235 (reg: 131,524, dir: 26,711)
> Number of deleted files: 0
> Number of regular files transferred: 131,524
> Total file size: 208.96M bytes
> Total transferred file size: 208.96M bytes
> Literal data: 208.96M bytes
> Matched data: 0 bytes
> File list size: 3.90M
> File list generation time: 0.001 seconds
> File list transfer time: 0.000 seconds
> Total bytes sent: 2.71M
> Total bytes received: 218.79M
>
> sent 2.71M bytes  received 218.79M bytes  56.02K bytes/sec
> total size is 208.96M  speedup is 0.94
>  * Manifest timestamp: 2020-01-12 18:38:55 UTC
>  * Valid OpenPGP signature found:
>  * - primary key: DCD05B71EAB94199527F44ACDB6B8C1F96D8BF6D
>  * - subkey: E1D6ABB63BFCFB4BA02FDF1CEC590EEAC9189250
>  * - timestamp: 2020-01-12 18:38:55 UTC
>  * Verifying /var/db/repos/gentoo/.tmp-unverified-download-quarantine
> ...!!! Manifest v>
> Manifest mismatch for media-plugins/Manifest.gz
>   __size__: expected: 48363, have: 48349
>
>
> Inodes?  That's an interesting thought.  Not sure how I'd check that ...
> I'll redirect the output into a file next time.
>
> What would I look for in the top(1) status lines (the lines at the top
> before the process table?)?
>
> With emerge-webrsync do you mean webrsync or is there some additional
> facility

The df command will give you that info.  This is a example just replace
your device with the one I used.

df -i /dev/sdb1

Hope that helps.

Dale

:-)  :-) 

Reply | Threaded
Open this post in threaded view
|

Re: .tmp-unverified-download-quarantine

Peter Humphrey-3
In reply to this post by n952162
On Tuesday, 14 January 2020 11:07:34 GMT n952162 wrote:
> On 2020-01-14 11:10, Peter Humphrey wrote:
--->8

> >> This is a fresh install from a minimal cd image.  I'm starting out with
> >> mkfs.  I've tried that 3 times, twice using a stage 3 from 2020/01/08
> >> and once using a stage 3 from 2020/01/12.
> >
> > Er...you aren't running out of disk space, are you (either physical space
> > or inodes)? Don't forget /tmp and /var/tmp. And what result did 'emerge
> > --sync' return? Specifically, did you see a 'Sync completed' message?
> > Have you watched /usr/bin/top status lines while syncing?
> >
> > And have you actually tried emerge-webrsync?
>
> 'emerge --sync' gave me status 1 and before that, the error about the
> manifest:

I didn't see a manifest error before; perhaps I overlooked it.

> Number of files: 158,236 (reg: 131,524, dir: 26,712)
> Number of created files: 158,235 (reg: 131,524, dir: 26,711)
> Number of deleted files: 0
> Number of regular files transferred: 131,524
> Total file size: 208.96M bytes
> Total transferred file size: 208.96M bytes
> Literal data: 208.96M bytes
> Matched data: 0 bytes
> File list size: 3.90M
> File list generation time: 0.001 seconds
> File list transfer time: 0.000 seconds
> Total bytes sent: 2.71M
> Total bytes received: 218.79M
>
> sent 2.71M bytes  received 218.79M bytes  56.02K bytes/sec

HOW long?! 56KB/s shows something going badly wrong.

> total size is 208.96M  speedup is 0.94

I've never seen a speedup less than 1 before.

>   * Manifest timestamp: 2020-01-12 18:38:55 UTC
>   * Valid OpenPGP signature found:
>   * - primary key: DCD05B71EAB94199527F44ACDB6B8C1F96D8BF6D
>   * - subkey: E1D6ABB63BFCFB4BA02FDF1CEC590EEAC9189250
>   * - timestamp: 2020-01-12 18:38:55 UTC
>   * Verifying /var/db/repos/gentoo/.tmp-unverified-download-quarantine
> ...!!! Manifest v>
> Manifest mismatch for media-plugins/Manifest.gz
>    __size__: expected: 48363, have: 48349

That would indeed leave the tree safely in quarantine.

> Inodes?  That's an interesting thought.  Not sure how I'd check that ...
> I'll redirect the output into a file next time.
>
> What would I look for in the top(1) status lines (the lines at the top
> before the process table?)?

I'd want to see how much memory and swap were consumed and available; the
processor load may offer you a clue too.
 
> With emerge-webrsync do you mean webrsync or is there some additional
> facility?

According to the Wiki* the first thing you do after chrooting into the new
system is to issue the command 'emerge-webrsync'. I suggest you try it.


*  https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Base#Installing_an_ebuild_repository_snapshot_from_the_web

--
Regards,
Peter.




Reply | Threaded
Open this post in threaded view
|

Fw: Re: [gentoo-user] .tmp-unverified-download-quarantine

n952162
I guess you're referring to this:

"The use of emerge-webrsync is recommended for those who are behind restrictive firewalls (because it uses HTTP/FTP protocols for downloading the snapshot) and saves network bandwidth. Readers who have no network or bandwidth restrictions can happily skip down to the next section."

Indeed that was a sub-theme of my question (although I oversaw that "emerge-" was indeed part of the command): could that have an impact on my problem?  I'm not behind a firewall and have no bandwidth restrictions (DSL).  It's a bad state when you start having to do things which are nominally not relevant, because you don't have anything else to lose (but time).  That's called "grasping at straws"


> Gesendet: Dienstag, 14. Januar 2020 um 16:47 Uhr
> Von: "Peter Humphrey" <[hidden email]>
> An: [hidden email]
> Betreff: Re: [gentoo-user] .tmp-unverified-download-quarantine
>
> On Tuesday, 14 January 2020 11:07:34 GMT n952162 wrote:
> > On 2020-01-14 11:10, Peter Humphrey wrote:
> --->8
> > >> This is a fresh install from a minimal cd image.  I'm starting out with
> > >> mkfs.  I've tried that 3 times, twice using a stage 3 from 2020/01/08
> > >> and once using a stage 3 from 2020/01/12.
> > >
> > > Er...you aren't running out of disk space, are you (either physical space
> > > or inodes)? Don't forget /tmp and /var/tmp. And what result did 'emerge
> > > --sync' return? Specifically, did you see a 'Sync completed' message?
> > > Have you watched /usr/bin/top status lines while syncing?
> > >
> > > And have you actually tried emerge-webrsync?
> >
> > 'emerge --sync' gave me status 1 and before that, the error about the
> > manifest:
>
> I didn't see a manifest error before; perhaps I overlooked it.
>
> > Number of files: 158,236 (reg: 131,524, dir: 26,712)
> > Number of created files: 158,235 (reg: 131,524, dir: 26,711)
> > Number of deleted files: 0
> > Number of regular files transferred: 131,524
> > Total file size: 208.96M bytes
> > Total transferred file size: 208.96M bytes
> > Literal data: 208.96M bytes
> > Matched data: 0 bytes
> > File list size: 3.90M
> > File list generation time: 0.001 seconds
> > File list transfer time: 0.000 seconds
> > Total bytes sent: 2.71M
> > Total bytes received: 218.79M
> >
> > sent 2.71M bytes  received 218.79M bytes  56.02K bytes/sec
>
> HOW long?! 56KB/s shows something going badly wrong.
>
> > total size is 208.96M  speedup is 0.94
>
> I've never seen a speedup less than 1 before.
>
> >   * Manifest timestamp: 2020-01-12 18:38:55 UTC
> >   * Valid OpenPGP signature found:
> >   * - primary key: DCD05B71EAB94199527F44ACDB6B8C1F96D8BF6D
> >   * - subkey: E1D6ABB63BFCFB4BA02FDF1CEC590EEAC9189250
> >   * - timestamp: 2020-01-12 18:38:55 UTC
> >   * Verifying /var/db/repos/gentoo/.tmp-unverified-download-quarantine
> > ...!!! Manifest v>
> > Manifest mismatch for media-plugins/Manifest.gz
> >    __size__: expected: 48363, have: 48349
>
> That would indeed leave the tree safely in quarantine.
>
> > Inodes?  That's an interesting thought.  Not sure how I'd check that ...
> > I'll redirect the output into a file next time.
> >
> > What would I look for in the top(1) status lines (the lines at the top
> > before the process table?)?
>
> I'd want to see how much memory and swap were consumed and available; the
> processor load may offer you a clue too.
>
> > With emerge-webrsync do you mean webrsync or is there some additional
> > facility?
>
> According to the Wiki* the first thing you do after chrooting into the new
> system is to issue the command 'emerge-webrsync'. I suggest you try it.
>
>
> *  https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Base#Installing_an_ebuild_repository_snapshot_from_the_web
>
> --
> Regards,
> Peter.
>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: .tmp-unverified-download-quarantine

Neil Bothwick
In reply to this post by Peter Humphrey-3
On Tue, 14 Jan 2020 15:47:51 +0000, Peter Humphrey wrote:

> > sent 2.71M bytes  received 218.79M bytes  56.02K bytes/sec  
>
> HOW long?! 56KB/s shows something going badly wrong.

This sounds like it could be a network problem. Have you used
mirrorselect?
 

> > total size is 208.96M  speedup is 0.94  
>
> I've never seen a speedup less than 1 before.
>
> >   * Manifest timestamp: 2020-01-12 18:38:55 UTC
> >   * Valid OpenPGP signature found:
> >   * - primary key: DCD05B71EAB94199527F44ACDB6B8C1F96D8BF6D
> >   * - subkey: E1D6ABB63BFCFB4BA02FDF1CEC590EEAC9189250
> >   * - timestamp: 2020-01-12 18:38:55 UTC
> >   * Verifying /var/db/repos/gentoo/.tmp-unverified-download-quarantine
> > ...!!! Manifest v>
> > Manifest mismatch for media-plugins/Manifest.gz
> >    __size__: expected: 48363, have: 48349  
>
> That would indeed leave the tree safely in quarantine.
I wondered if the file was truncated from some sort of network problem,
until I checked my tree and saw that that file was 48349 bytes and
portage was really happy.
 

> > Inodes?  That's an interesting thought.  Not sure how I'd check that
> > ... I'll redirect the output into a file next time.
> >
> > What would I look for in the top(1) status lines (the lines at the top
> > before the process table?)?  
>
> I'd want to see how much memory and swap were consumed and available;
> the processor load may offer you a clue too.
>  
> > With emerge-webrsync do you mean webrsync or is there some additional
> > facility?  
>
> According to the Wiki* the first thing you do after chrooting into the
> new system is to issue the command 'emerge-webrsync'. I suggest you try
> it.
I would definitely try emerge-webrsync as it downloads a consistent
snapshot of the system. You say you have no network or bandwidth
restrictions, but 56K/s says otherwise.


--
Neil Bothwick

... but you can't expect to wield supreme executive power just because
some watery tart threw a sword at you!

attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Fw: Re: [gentoo-user] .tmp-unverified-download-quarantine

Peter Humphrey-3
In reply to this post by n952162
On Tuesday, 14 January 2020 18:36:23 GMT [hidden email] wrote:

> I guess you're referring to this:
>
> "The use of emerge-webrsync is recommended for those who are behind
> restrictive firewalls (because it uses HTTP/FTP protocols for downloading
> the snapshot) and saves network bandwidth. Readers who have no network or
> bandwidth restrictions can happily skip down to the next section."
>
> Indeed that was a sub-theme of my question (although I oversaw that
> "emerge-" was indeed part of the command): could that have an impact on my
> problem?  I'm not behind a firewall and have no bandwidth restrictions
> (DSL).  It's a bad state when you start having to do things which are
> nominally not relevant, because you don't have anything else to lose (but
> time).  That's called "grasping at straws"

Why don't you just try it? What could you lose?

"When all else fails, read the instructions."

--
Regards,
Peter.




Reply | Threaded
Open this post in threaded view
|

Fw: Re: Re: [gentoo-user] .tmp-unverified-download-quarantine

n952162
In what way is emerge sensitive to reduced bandwidth?

> Gesendet: Donnerstag, 16. Januar 2020 um 11:48 Uhr
> Von: "Peter Humphrey" <[hidden email]>
> An: n952162 <[hidden email]>
> Betreff: Re: Fw: Re: [gentoo-user] .tmp-unverified-download-quarantine
>
> On Thursday, 16 January 2020 07:28:19 GMT you wrote:
>
> > But it's not synced, and that's the point in the end.
>
> Well, it isn't far off. The tarball will have been made no earlier than the
> previous day.
>
> > Now I don't know, if I run emerge --sync, will it corrupt the system
> > I've just installed?
>
> I can't see how. The worst it can do is to repeat your original problem, and
> you'll be no worse off except for the disk space used. If the --sync fails on
> verification, the new portage tree will be left in quarantine; that's what the
> verification step is for.
>
> I've reinstalled systems here recently more often than I can count, and I've
> always gone on from emerge-webrsync without another --sync. When I have a
> bootable system I do boot it, then finish the system build natively, as it
> were.
>
> When all packages have been installed and configured, I do a --sync and an -e
> @world, just to make sure everything fits together properly*.
>
> You will need to do something about that DSL link though, if it's still as bad
> while running your new system.
>
> * Actually, I'm more paranoid than that: I do an emerge @system, then
> recompile and reboot the kernel, then an -e @world minus what was installed by
> @system. I've no doubt that all the experts would say it's pointless, but I
> learned caution when I was leading the team that maintained the 15-mainframe
> system at five control centres that runs the national grid in England and
> Wales. That was 25 years ago, but some habits stick - and CPU cycles are
> cheap.
>
> --
> Regards,
> Peter.
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: .tmp-unverified-download-quarantine

james-3
In reply to this post by n952162
On 1/13/20 3:24 AM, n952162 wrote:

> On 2020-01-12 16:48, james wrote:
>> I also install and re-install, as many of the gentoo systems get
>> "attacked" before I can� complete a secure install, or the hackers
>> just read much more than I do.
>> I guess I'm still popular, in very negative way.
>
>
> Hmmm.� Is that "attacked" to be interpreted in some sort of metaphorical
> way or do you mean really hacked over the internet? May I ask how, and
> how do you know?� What's involved in a secure install?


Monitor your connection, with a system setup that the ethernet does not
responds to any sort of request. The system just collects and log. NO,
I'm not documenting how to do this, but various ways exist, documented
on the internet to make *most* ethernet interface to where they are
*one-direction* only. HOW you achieve this? There are a myriad of ways.

Good Hunting and *never* tell anyone how *you* do this....


caveat emptor

James

Reply | Threaded
Open this post in threaded view
|

Re: .tmp-unverified-download-quarantine

james-3
In reply to this post by n952162
On 1/13/20 3:24 AM, n952162 wrote:

> On 2020-01-12 16:48, james wrote:
>> I also install and re-install, as many of the gentoo systems get
>> "attacked" before I can� complete a secure install, or the hackers
>> just read much more than I do.
>> I guess I'm still popular, in very negative way.
>
>
> Hmmm.� Is that "attacked" to be interpreted in some sort of metaphorical
> way or do you mean really hacked over the internet? May I ask how, and
> how do you know?� What's involved in a secure install?
>
>


Here is a good place *to start* self-education::


https://en.wikipedia.org/wiki/Unidirectional_network

Reply | Threaded
Open this post in threaded view
|

Re: .tmp-unverified-download-quarantine

Wols Lists
In reply to this post by james-3
On 16/01/20 21:01, james wrote:

> On 1/13/20 3:24 AM, n952162 wrote:
>> On 2020-01-12 16:48, james wrote:
>>> I also install and re-install, as many of the gentoo systems get
>>> "attacked" before I can� complete a secure install, or the hackers
>>> just read much more than I do.
>>> I guess I'm still popular, in very negative way.
>>
>>
>> Hmmm.� Is that "attacked" to be interpreted in some sort of
>> metaphorical
>> way or do you mean really hacked over the internet? May I ask how, and
>> how do you know?� What's involved in a secure install?
>
>
> Monitor your connection, with a system setup that the ethernet does not
> responds to any sort of request. The system just collects and log. NO,
> I'm not documenting how to do this, but various ways exist, documented
> on the internet to make *most* ethernet interface to where they are
> *one-direction* only. HOW you achieve this? There are a myriad of ways.
>
> Good Hunting and *never* tell anyone how *you* do this....
>
If you're handy with an ethernet crimping tool, just cut the TX wires
and put the interface into promiscuous mode ...

Just be aware that - routers especially - can swap TX and RX so they
could possibly get round that.

Cheers,
Wol


Reply | Threaded
Open this post in threaded view
|

Re: .tmp-unverified-download-quarantine

n952162
What protocol doesn't use acknowledgements?


On 2020-01-18 14:50, Wols Lists wrote:

> On 16/01/20 21:01, james wrote:
>> On 1/13/20 3:24 AM, n952162 wrote:
>>> On 2020-01-12 16:48, james wrote:
>>>> I also install and re-install, as many of the gentoo systems get
>>>> "attacked" before I can� complete a secure install, or the hackers
>>>> just read much more than I do.
>>>> I guess I'm still popular, in very negative way.
>>>
>>> Hmmm.� Is that "attacked" to be interpreted in some sort of
>>> metaphorical
>>> way or do you mean really hacked over the internet? May I ask how, and
>>> how do you know?� What's involved in a secure install?
>>
>> Monitor your connection, with a system setup that the ethernet does not
>> responds to any sort of request. The system just collects and log. NO,
>> I'm not documenting how to do this, but various ways exist, documented
>> on the internet to make *most* ethernet interface to where they are
>> *one-direction* only. HOW you achieve this? There are a myriad of ways.
>>
>> Good Hunting and *never* tell anyone how *you* do this....
>>
> If you're handy with an ethernet crimping tool, just cut the TX wires
> and put the interface into promiscuous mode ...
>
> Just be aware that - routers especially - can swap TX and RX so they
> could possibly get round that.
>
> Cheers,
> Wol
>
>


Reply | Threaded
Open this post in threaded view
|

Re: .tmp-unverified-download-quarantine

Wols Lists
On 18/01/20 17:45, n952162 wrote:
> What protocol doesn't use acknowledgements?
>
Why would an eavesdropper want to acknowledge ANYTHING? Isn't that the
whole point?

Cheers,
Wol

>
> On 2020-01-18 14:50, Wols Lists wrote:
>> On 16/01/20 21:01, james wrote:
>>> On 1/13/20 3:24 AM, n952162 wrote:
>>>> On 2020-01-12 16:48, james wrote:
>>>>> I also install and re-install, as many of the gentoo systems get
>>>>> "attacked" before I can� complete a secure install, or the hackers
>>>>> just read much more than I do.
>>>>> I guess I'm still popular, in very negative way.
>>>>
>>>> Hmmm.� Is that "attacked" to be interpreted in some sort of
>>>> metaphorical
>>>> way or do you mean really hacked over the internet? May I ask how, and
>>>> how do you know?� What's involved in a secure install?
>>>
>>> Monitor your connection, with a system setup that the ethernet does not
>>> responds to any sort of request. The system just collects and log. NO,
>>> I'm not documenting how to do this, but various ways exist, documented
>>> on the internet to make *most* ethernet interface to where they are
>>> *one-direction* only. HOW you achieve this? There are a myriad of ways.
>>>
>>> Good Hunting and *never* tell anyone how *you* do this....
>>>
>> If you're handy with an ethernet crimping tool, just cut the TX wires
>> and put the interface into promiscuous mode ...
>>
>> Just be aware that - routers especially - can swap TX and RX so they
>> could possibly get round that.
>>
>> Cheers,
>> Wol
>>
>>
>
>


12