Re: [hlds] Test

[Kit Parenteau]

Just a collector address is subscribed. Amy is the presence of many
throwaway addresses used once the poster has been sucked from the list. Not
much that can be done for it honestly. If the collector address is found
and removed, they could join a new one anyway. They just have a bad
audience here. Nobody on this list is stupid enough to fall for it.

On Fri, Sep 11, 2015, 5:29 PM Eric Smith  wrote:

> On that topic, Amy is not subscribed to this list so we don't have an
> action we can take here.
>
> -Eric
>
>
>
> From: hlds-boun...@list.valvesoftware.com [mailto:
> hlds-boun...@list.valvesoftware.com] On Behalf Of Weasels Lair
> Sent: Friday, September 11, 2015 11:54 AM
> To: Half-Life dedicated Win32 server mailing list
> Subject: Re: [hlds] Test
>
> She's not YOUR Amy! She's obviously mine! She keeps e-mailing ME!
>
>
> On Sep 11, 2015 11:42 AM, "N-Gon"  wrote:
> Not my amy!
>
>
> On Fri, Sep 11, 2015 at 2:28 PM, Daniel Barreiro <
> smelly.feet.you.h...@gmail.com> wrote:
> Is this change to help stop the spambots by any chance?
>
>
> On Fri, Sep 11, 2015 at 2:26 PM, Eric Smith 
> wrote:
> Testing a mailing list change. No need to reply. Thanks.
>
> -Eric
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds
>
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds

Re: [hlds] Community Servers and the Gun Mettle Update

[Kit Parenteau]

Here's a little interesting take on this (Not directed at anybody in 
particular, just at the concept in general)...


There are some Bad Apples amongst the community server folks. Community 
servers were meant to enhance the game experience for the players. 
Instead we have operators whose only goal is to drag in as many clients 
as possible for their ad impression, even if it's "cheating" both the 
players and ad company by playing ads invisibly in the background.


While there were many good servers out there too, the bad servers grew 
in number until the situation became untenable. Extra things were done 
by Valve to try to stem the flow of Greedy Little Server Operators and 
all their methods of trying to cheat the system. What should have been a 
case of good servers thriving and bad servers dying became the opposite. 
The cheating scumbags were the ones thriving and so - from the player 
perspective - the game sucked.


Because of all the worms and bugs living in the apple barrel, Valve had 
to do what it did. They -are- a business, which means that yes, their 
goal is to make money, and yes, if the community servers were preventing 
that, then action would be taken. And it was. And the whining and 
groaning was heard by many of the worms who could no longer feast on ad 
impressions.


Now, mind you, not all of the whining was heard by worms. Some 
legitimate, quality server operators had trouble too. However the end 
result is simple:


Nobody should be running a community server to try to make a profit. If 
they are doing so, they have to realize that it's officially a business 
and may fail. Bad business plan? Crappy user experience? Not interesting 
enough to hold users' attention? *Poof!* Bye! As long as the net result 
to Valve from community servers is negative, they will not fix it.


From the cynical side, the people who are doing just fine with their 
community servers are sitting back and thrilled that the worms are 
suffering. They're seeing people saying "OMG! IMMA SHUT DOWN MAH 
SERVER!" and laughing that these people think Valve care. If the server 
does not create a positive experience and bring Valve money, then why in 
the world should Valve care? They are not here to create free ways for 
people to make an income. So, from the cynical side, please, stop 
whining about how you'll shut down your servers. Shut them down and 
begone. Let the people who are doing fine live in peace from the inanely 
incessant prattle, assuming they are even on this list when they are 
doing fine.


From the pragmatic side: If the server costs you too much money and you 
don't want to spend it, then don't. You don't owe Valve the server and 
they don't owe you anything either. Since you're not getting a bone from 
them, stop hurting yourself and your pocketbook. Shut down. Move on. 
There is a great big world out there and you should be awesome enough to 
stop beating your head against a brick wall.


TL;DR version:
Don't say that you're going to quit. Just do it. Don't cling to false 
hopes. Move on. Be happier.


Good luck to all.

On 9/3/2015 12:58 AM, Rowedahelicon wrote:
To be honest I forgot they even said it, and I'm usually way on top of 
this stuff. I've been preparing to close down my servers if I can't 
figure out a good advertising campaign, the silence has gotten deafening.


On Thu, Sep 3, 2015 at 12:05 AM, HD > wrote:


They won’t reply, nor will anything be changed with Valve servers.

Personally I’d like to see the amount of them cut in half and I
believe the suggestion was to remove it from defaults after a
specified amount of time played but as I said…never happen.

Replying as you did just makes me feel like something will happen,
kinda like waiting for a unicorn to appear.

*From:*hlds-boun...@list.valvesoftware.com

[mailto:hlds-boun...@list.valvesoftware.com
] *On Behalf Of
*Alexander Corn
*Sent:* Wednesday, September 02, 2015 11:57 PM
*To:* Half-Life dedicated Win32 server mailing list
*Subject:* Re: [hlds] Community Servers and the Gun Mettle Update

>We agree this is not ideal. We are continuing the look at the
situation with community servers and how we can better support
passionate communities, but currently have nothing to announce.

So how's it coming? It's been a few months now and as usual,
nothing has happened. I know that as without being a server op, I
would find Valve servers distasteful. There's something about
being votekicked for killing players on the other team that just
makes the gameplay experience unsatisfactory.

Thanks,

Alexander "Dr. McKay" Corn

On Thu, Jul 2, 2015 at 5:22 PM, John Schoenick
> wrote:

Hey guys, with today's update we're introducing a few 

Re: [hlds] Someone took over server

[Kit Parenteau]

Whitelisting home connections is rather pointless since the majority 
have dynamic IP addresses that constantly change. Then there's the 
problem that IP addresses can be easily spoofed.


The inbound packets can be source-spoofed, but full TCP links and return 
UDP will not reach the spoofer unless ARP poisoning or something similar 
enough is used. In cases of UDP being listened to without caring whether 
the reply gets to where it's supposed to go, spoofing will work. TCP? 
Not so much unless you can get into the network between the source and 
the destination and even then it's a pain. Home IP addresses changing is 
a challenge though.


___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds

Re: [hlds] (no subject)

[Kit Parenteau]

Notably, both Google and Microsoft do not give the end-user originating 
IP of email from the web interface and this cannot be retrieved without 
a subpoena. (Claims to the contrary may be backed up with hard evidence 
or will be disregarded by intelligent people on this list.)


Example of origin from Google using the web interface:

Received: by 10.204.4.205 with HTTP; Sun, 16 Jun 2013 17:52:30 -0700 (PDT)

Just that. Google's internal server. After that, it will prepend MIME 
info, an X-received, and a DKIM signature before handing it off to the 
Google SMTP server. Further tracks will show arriving from Google's servers.


Example of masked origin from Microsoft's system:

Received: from BAY174-W22 ([65.54.190.60]) by bay0-omc1-s26.bay0.hotmail.com
 with Microsoft SMTPSVC(6.0.3790.4675);

The general edge it came from can be determined to a degree, but not the 
end user origination information and the edge can be manipulated.


So no, origin IP cannot be determined in those cases. Even if it could 
it is trivial to use TOR or other similar systems to mask that.


However, it's trivial to simply read the messages provided by anybody 
involved and see the differences in tone and content and make educated 
decisions based on that.  It's not at all hard to trash anything coming 
from addresses that show poor judgement in selection of verbiage.


The list becomes a lot more manageable and pleasant in cases where any 
message that is either from or responding to known-problems is dropped 
in the bit bucket.


___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds

Re: [hlds] TF2 MOTD and Quickplay

[Kit Parenteau]

- Too much interlinked functionality. Serving up background music in the 
MOTD is somewhat popular, for example.
- Unless disabled is the default, it fails to protect the users who 
need the most protection (new and unwitting users).
- Being all-or-nothing without other functionality comes back to the 
first issue above.


It all does come down to how much effort Valve will put into correcting 
the issue. From a security and abuse standpoint, it's just an utter 
mess. Cleaning it up properly without killing functionality isn't a 
small undertaking either. Major coding, custom script handling to 
interject permission requests, or hard blocks of functionality that may 
or may not have an API to intercept. Then no matter what you allow and 
block, there is liable to be a legitimate function relying on that or 
some abusive manner of circumventing the restrictions.  Cat and mouse, 
and sometimes legitimate uses take the fall if the abuse gets too heavy.



On 6/16/2013 7:50 PM, Paul wrote:
Or simply just disable HTML motds in your options and stop feeding 
threads such as this with nonsense about deleting the MOTD entirely or 
such like?





___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds

Re: [hlds] Windows Server and symbolic links

[Kit Parenteau]

GE could take a page from your book then, since it sounds like they are 
doing something similar but trying to update the split trunks manually.


A symlink in Windows is that odd and slightly annoying *.lnk file.  It 
works in SOME situations when Windows is directly involved.  Sadly, it 
takes special whacking at Windows with a wrench to make it deal with 
file junctions (hard links).


So, from what I understand, you've got something like (VERY simplified):
\server1\
 -\server1\data\
 -\server1\config\
 -\server1\logs\
\server2\
-\server2\data\ - \server1\data\
-\server2\config\
-\server2\logs\
\server3\
-\server3\data\ - \server1\data\
-\server3\config\
-\server3\logs\

Then you have all the binaries in each server directory copied from 
server1 and the data linked to \server1\data\ from each extra server.


So GE does an update on server1, then instead of manually copying the 
binaries to server2\ and server3\, they try to do an update on those 
servers, which will just wipe and re-update the data directory stuff.


By comparison, you can instead have
\server\
-\server\data\
-\server\config1\
-\server\config2\
-\server\config3\
-\server\logs1\
-\server\logs2\
-\server\logs3\

Create a symlink/shortcut/batch file/whatever, and use such lovely 
things as +servercfgfile server1\server.cfg +logsdir logs1 for the first 
server, and change the command line for each server.


Since the .exe binary should be released when it's finished loading the 
image into memory, you can run multiple servers off the same binary.  
DLLs, when well-written, will be determined to be the same file, so can 
use shared images in RAM, thus saving memory space and performance.

then start the server


On 9/5/2012 10:39 PM, Dmitriy Bobrovskiy wrote:

Actually you're right. I use directory junctions.
Yes, I don't run update tool for each server ;)
I manually copy binary content to all servers after each update but keep 
content like maps/models and so on linked to 'master' folders.


You're better off

I'm not sure I've understood you properly. What did you mean?

And what are symlinks in Windows? Are they just ' junctions' for each file?



-Original Message-
From: hlds-boun...@list.valvesoftware.com [mailto:hlds-
boun...@list.valvesoftware.com] On Behalf Of Kit Parenteau
Sent: Thursday, September 06, 2012 4:32 AM
To: Half-Life dedicated Win32 server mailing list
Subject: Re: [hlds] Windows Server and symbolic links

Are you using symlinks or directory junctions?

Unfortunately, the fact that running an update will use the base information
to do a nuke and re-install means that if you have server code in multiple
directories and the data files shared, it will still nuke the data files when it
finds the old code.

You're better off, as said by the prior respondent, keeping one code base
and pointing at configs and logs at run-time with command line parameters.
Failing at this, you'd have to manually update your separate trunks with the
needed code to avoid having the update tool do so.

On 9/5/2012 1:55 PM, Dmitriy Bobrovskiy wrote:

I also update so called 'master' image. But I have several servers and all of

their folders are symlinks to the master image except folders with configs,
logs, etc.



-Original Message-
From: hlds-boun...@list.valvesoftware.com [mailto:hlds-
boun...@list.valvesoftware.com] On Behalf Of Rudy Bleeker
Sent: Wednesday, September 05, 2012 8:16 PM
To: Half-Life dedicated Win32 server mailing list
Subject: Re: [hlds] Windows Server and symbolic links

This is because of the way the update process works. It's an all or
nothing deal really. When you trigger an update, the hldsupdatetool
will report the current version of the installation to the update
servers. Then it recieves a list of all the files that should be
outdated and need to be thrown away and redownloaded.

So even though your individual mapfiles are already up-to-date, the
second hlds installation still reports and older version to the
update servers, which then assumes the files need to be reaquired.

I don't think there is an easy way to 'fix' this, since it's not
really broken, just a design choice. In my case I just run all my TF2
server from one installation, exec'ing different config files from
the cfg folder, depending on the type of server I want to run. I've
also turned autoupdate off, so there won't be multiple update
processes started at an update. When an update goes live I just shut
down all the servers, run one update and then start the servers
again. Of course, I'm running it all on Linux, but that shouldn't
matter much, on windows you could just save the startup lines in batch

scripts or notepad or whatever.

On Wed, Sep 5, 2012 at 5:46 PM, GE gamersex...@shaw.ca wrote:

Recently I've added symlinks on my TF2 servers to save space and
reduced

bandwidth on updates, however this does not seem to help when using
hldsupdatetool.

At this point only the maps folder has been linked.

Server 1 (master) update runs

Re: [hlds] Windows Server and symbolic links

[Kit Parenteau]

Are you using symlinks or directory junctions?

Unfortunately, the fact that running an update will use the base 
information to do a nuke and re-install means that if you have server 
code in multiple directories and the data files shared, it will still 
nuke the data files when it finds the old code.


You're better off, as said by the prior respondent, keeping one code 
base and pointing at configs and logs at run-time with command line 
parameters.  Failing at this, you'd have to manually update your 
separate trunks with the needed code to avoid having the update tool do so.


On 9/5/2012 1:55 PM, Dmitriy Bobrovskiy wrote:

I also update so called 'master' image. But I have several servers and all of 
their folders are symlinks to the master image except folders with configs, 
logs, etc.



-Original Message-
From: hlds-boun...@list.valvesoftware.com [mailto:hlds-
boun...@list.valvesoftware.com] On Behalf Of Rudy Bleeker
Sent: Wednesday, September 05, 2012 8:16 PM
To: Half-Life dedicated Win32 server mailing list
Subject: Re: [hlds] Windows Server and symbolic links

This is because of the way the update process works. It's an all or nothing
deal really. When you trigger an update, the hldsupdatetool will report the
current version of the installation to the update servers. Then it recieves a 
list
of all the files that should be outdated and need to be thrown away and
redownloaded.

So even though your individual mapfiles are already up-to-date, the second
hlds installation still reports and older version to the update servers, which
then assumes the files need to be reaquired.

I don't think there is an easy way to 'fix' this, since it's not really broken, 
just a
design choice. In my case I just run all my TF2 server from one installation,
exec'ing different config files from the cfg folder, depending on the type of
server I want to run. I've also turned autoupdate off, so there won't be
multiple update processes started at an update. When an update goes live I
just shut down all the servers, run one update and then start the servers
again. Of course, I'm running it all on Linux, but that shouldn't matter much,
on windows you could just save the startup lines in batch scripts or notepad
or whatever.

On Wed, Sep 5, 2012 at 5:46 PM, GE gamersex...@shaw.ca wrote:

Recently I've added symlinks on my TF2 servers to save space and reduced

bandwidth on updates, however this does not seem to help when using
hldsupdatetool.

At this point only the maps folder has been linked.

Server 1 (master) update runs as expected.
Server 2 (slave) update runs but deletes files previously downloaded and

re-downloads them ie latest tf2 update 4 maps that were updated, each
slave server then removes and re-downloads mvm_decoy (etc).

Should the update not see that the maps are the latest version and don't

need to be replaced? Or am I missing a symlink somewhere else?

Windows server 2008r2

Thanks,

GE




___
To unsubscribe, edit your list preferences, or view the list archives, please

visit:

https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds



--
Idleness is not doing nothing. Idleness is being free to do anything.
   - Floyd Dell

___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds


___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds




___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds

Re: [hlds] Policy of Truth Still in effect? Fast Respawn without tags OK?

[Kit Parenteau]

Okay, seriously guys, this list's occupants are great most of the time, 
but sometimes a thread makes me feel like I'm on the World of Warcraft 
forums.


Speculation is fun and all, but until an official statement comes in, 
that's all it can be: Speculation.


Just please, before posting, think about what's being said and whether 
it goes against even just common sense.


Is it cool that servers cheat and get more players for it? Probably not.
Should it be handled?  Probably.
How should it be handled?  Some folks have had really good observations 
on the thread that maybe the policy or handling needs to be redefined.
Will somebody be butt-hurt from handling things?  Always.  Whether they 
are hurt from it not being handled or hurt because OMG, U B ME! or 
because they feel it wasn't handled the way they would have done it, the 
rear ends will be in pain.


People who follow the rules take a penalty from people who don't and 
can't fill their servers!...
Then why are there as many full rule-following servers out there as 
there are?  Perhaps, when cheating takes away a free handout, rather 
than waiting for somebody else to fix it, figure out how to become like 
a full non-cheating server.


Does not knowing the speed limit excuse you from a speeding ticket?
I guess you don't drive much, because yes, it absolutely can.  While one 
shouldn't RELY on it, because it's not an absolute (see that not black 
and white thing), it's perfectly possible.  Although a better example, 
since the link was shaky at best, would be too big a diameter tire 
putting 10% speed or so above what the speedometer says.


But really, the people who are complaining about the issue right now 
seem to be more interested in complaining to complain and be annoying 
than to help find solutions that make sense.  So take a step back and 
think about it before clicking post.  If the message sounds like a whiny 
forum post from WoW forums...  It probably won't help you get your way.


___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds