[X] My Assistant

1.5.1 was released, check the OP. This just has a minor performance improvement (1.5.0 would allocate a new temporary buffer for every TCP write, 1.5.1 just makes one buffer and reuses it for the full session), as well as a fix to the Linux build scripts.

My trust is taking repeated serious hits, and I'm not sure why. On the other hand, my quality is capped out. I am not aware of any connection issues on my end. This happened once yesterday and then spent the day recovering, and has apparently happened again overnight, despite serving files perfectly fine (from what I can observe).

Is this happening to anyone else using 1.5.0?

1.5 is actually averaging a higher trust than pre-1.5 clients, which is a bit weird since the scoring is the same. For you, it seems to be just an artifact of a smaller pool of testing clients. I made some tweaks to prevent that from happening as much, but your trust never actually dropped to 0, so it wouldn't have had much of an effect.

1.5.1 was released, check the OP. This just has a minor performance improvement (1.5.0 would allocate a new temporary buffer for every TCP write, 1.5.1 just makes one buffer and reuses it for the full session), as well as a fix to the Linux build scripts.
1.5 is actually averaging a higher trust than pre-1.5 clients, which is a bit weird since the scoring is the same. For you, it seems to be just an artifact of a smaller pool of testing clients. I made some tweaks to prevent that from happening as much, but your trust never actually dropped to 0, so it wouldn't have had much of an effect.

Thank you for the explanation.

oh, my client has been down for some time... good time as any to update lol.

My trust is taking repeated serious hits, and I'm not sure why. On the other hand, my quality is capped out. I am not aware of any connection issues on my end. This happened once yesterday and then spent the day recovering, and has apparently happened again overnight, despite serving files perfectly fine (from what I can observe).

Is this happening to anyone else using 1.5.0?

Not to me, but some others have complained similar problem. Someone in my country even lost 30 Hits total from his clients.
In my case, I updated only one client to 1.5.0 and it has neither suffered hits decreasing, nor hits increasing, despite I modified all setting according to Tenboro's advice.
Maybe it's because of traffic distribution from HTTP, but I'm not sure about that.

You don't *have* to, but it does seem to help a bit. Right now, 1.5 clients running on port 443 are averaging 9141 quality while those that don't average 8931.

Your rules look correct, but you also have to change the port to 443 on the H@H settings page.

CODE

pkill -9 -f 'java -jar HentaiAtHome.jar'
su
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -p tcp --dport 7777 -j ACCEPT
iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-port 7777

After I update 1.5.0 to 1.5.1, I lately saw your comment that I should set the port to 443, not to 7777.
As the port was set to 7777 on my H@H setting page, I changed it to 443 then run the machine.
Unfortunately, it spurted some error message that could not connect to host and the client has failed the external connection test.
So I changed it back to 7777 on H@H setting page and then it worked well. This seems to be the opposite of what you advised.
Is there actually something wrong I did when I set redirect command, or it's nothing strange to set the port to 7777, not 443?

CODE

pkill -9 -f 'java -jar HentaiAtHome.jar'
su
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -p tcp --dport 7777 -j ACCEPT
iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-port 7777

After I update 1.5.0 to 1.5.1, I lately saw your comment that I should set the port to 443, not to 7777.
As the port was set to 7777 on my H@H setting page, I changed it to 443 then run the machine.
Unfortunately, it spurted some error message that could not connect to host and the client has failed the external connection test.
So I changed it back to 7777 on H@H setting page and then it worked well. This seems to be the opposite of what you advised.
Is there actually something wrong I did when I set redirect command, or it's nothing strange to set the port to 7777, not 443?

You just need to start H@H with --port=7777

CODE

java -jar HentaiAtHome.jar --port=7777

But I have a problem to start with port 7777,so I use the other port...

This post has been edited by j800930: Oct 18 2019, 09:36

Gallery Downloader doesn't work on H@H 1.5.1.

I don't see Gallery Downloader in the H@H status. The folder "download" is still empty.

Gallery Downloader doesn't work on H@H 1.5.1.

I don't see Gallery Downloader in the H@H status. The folder "download" is still empty.

There was a small server-side issue that prevented the downloader startup signal from being properly sent to 1.5 clients, this should be fixed now.

There was a small server-side issue that prevented the downloader startup signal from being properly sent to 1.5 clients, this should be fixed now.

Yes, it works now. I see the folders in "download" folder. Thanks (IMG:[invalid] style_emoticons/default/smile.gif)

Note 3: 1.2 is now considered EOL and can no longer be started up. If you are one of the 3 people still running a client with this version, you should shut it down and update ASAP, as the RPC endpoint will soon be removed.

hehe (IMG:[invalid] style_emoticons/default/wink.gif)

I think more information on the configuration of routing rules on Linux could be helpful. After some googling I did this:

CODE

$ iptables -A INPUT -p tcp --dport 443 -j ACCEPT
$ iptables -A INPUT -p tcp --dport 7777 -j ACCEPT
$ iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-port 7777

And ended up with

CODE

$ iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:https
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:cbt

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

$ iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
REDIRECT   tcp  --  anywhere             anywhere             tcp dpt:https redir ports 7777

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination

Does this seem right?

UPDATE: It's up and running and seems to work (IMG:[invalid] style_emoticons/default/smile.gif)

This post has been edited by casouri: Oct 20 2019, 03:40

Seems my h@h client to rpc server is just having too poor connection, whenever I start my client, it sometimes fails because speedtest procedure ends with "ssl connect error", when using the old client, it runs normal(although sometimes fails with slow speedtest result). I believe that's why my client quality decreases significantly, however it serves local region requests well, so I decide to keep running it.

seconding this.
mine is some different: the "max speed" from the hentaiathome.php page has significantly down to <1000 kb/s when the cilent restarted.
now it's ascending to 1500 kbps after few moments.
since it's a connection which upload speed has been set to 3584 kb/s max, i decided to run the https version (1.5.1) in the next few days.

This post has been edited by wakaba4465: Oct 20 2019, 18:21

How about adding another port 8443 for HTTPS? As 80 and 443 ports are normally disabled for some ISPs(like those in China Mainland)

AFAIK, Several software including Apache Tomcat is using 8443 port as its default SSL port, although we need to specify the port when using it for HTTPS connections (like [example.com] https://example.com:8443)

8443 to 443 is just like 8080 to 80, that's the main reason for me to suggest it.

Apparently, If we can tell the client to use HTTPS without listening to port 443 only, that would be better!

How about adding another port 8443 for HTTPS? As 80 and 443 ports are normally disabled for some ISPs(like those in China Mainland)

You can set it to 8443 if you want, but I'm not sure how much software out there would recognize it as a "common non-standard" port and allow it for that reason. The site itself wouldn't have to treat it any different though.

-----

This post has been edited by 0xDEADC0DE: Oct 22 2019, 23:19

Note that for Linux specifically, it can be complicated to let the java binary bind to low ports unless you run it as root, which is not recommended. Even if you let it with setcap, ld will then typically block unprivileged users from even running it without some trickery, as it becomes a "privileged executable" and some library paths are not trusted by default. It is easier to use --port to bind to an unprivileged port and then use iptables rules to forward the port, for example:
...

On Ubuntu I used authbind to grant access to a non-root process binding lower port.
My 3 servers are all running by the user 'hath' (nologin & non-sudoer) to run "/usr/bin/authbind --deep /usr/bin/java HentaiAtHome.jar" thru systemd and it succesfully using port 443 without root

after 40+ mins running and log checking, there seems to be no problem (other than I accidentally delete the cache on one of those machines which caused severe trust issues)

I think I recommend this method.



To make it clear, after authbind installed, i ran those commands:

CODE

sudo touch /etc/authbind/byport/443
sudo chmod 500 /etc/authbind/byport/443
sudo chown hath /etc/authbind/byport/443

hath in the last command is the user that own H@H directory and ran H@H java service, you should change it to your username (which own H@H directory and ran H@H java service)

Since English is not my mother tongue, I'm sorry if my sentences don't make sense, feel free to ask in this case

This post has been edited by MiBrony: Oct 22 2019, 11:09

On Ubuntu I used authbind to grant access to a non-root process binding lower port.

+1

authbind is pretty good, much simpler to understand than using setcap directly. Worth checking if one never dealt with iptables before.

authbind is indeed another option, but it's not in the default repo for all distros, and the way you set it up and use it is a bit fiddly. Still, might be preferable if iptables is scary to you, or your distro uses something else to manage netfilter.

Unfortunately clients are taking too big hit (trust randomly failing to minus values, quality max @ ~2200), reverting to old stable for now.

After a day's running all 3 of my H@H server runs fine, but when I check the log of them I get a plenty amount of crawler trying to access paths that don't exist. Now I don't think that using port 443 is a good idea, 8443 or some higher-than-1024 ports like that would be more reasonable because it's relatively safer and less chaotic(I mean the linux non-root low port thing).

btw, my distro is using ufw as front-end and i think iptables is the back-end, but I have no idea when i'm messing with iptables will it affect ufw. since one of them is a server in a server room far away, I really don't want to make a risk.

This post has been edited by MiBrony: Oct 24 2019, 10:05