[Support] Linuxserver.io - SWAG - Secure Web Application Gateway (Nginx/PHP/Certbot/Fail2ban)


Recommended Posts

For anyone running into issues following these instructions. 
AND you are running a non-bridged Google Wifi or On-Hub there is one additional change you need to make. 

 


By default, Google Wifi is utilizing port 80 to tell you to go download the Google Wifi app. 
To fix this switch off of the Default Google DNS inside of the Google Wifi app. 

I switched mine over to Cloudflare's new public DNS (1.1.1.1 and 1.0.0.1), saved the changes then restated the LetsEncrypt container and all was well. 

Not sure if this was already posted elsewhere, but I spent the past 48 hours banging my head trying to figure out what the issue was. 
So I figured the least I could do was post this up in hopes of sparing someone else a concussion. 

Link to comment
For anyone running into issues following these instructions. 
AND you are running a non-bridged Google Wifi or On-Hub there is one additional change you need to make. 

 

By default, Google Wifi is utilizing port 80 to tell you to go download the Google Wifi app. 
To fix this switch off of the Default Google DNS inside of the Google Wifi app. 

I switched mine over to Cloudflare's new public DNS (1.1.1.1 and 1.0.0.1), saved the changes then restated the LetsEncrypt container and all was well. 

Not sure if this was already posted elsewhere, but I spent the past 48 hours banging my head trying to figure out what the issue was. 
So I figured the least I could do was post this up in hopes of sparing someone else a concussion. 
Damn Google

Sent from my BND-L34 using Tapatalk

Link to comment

Hi everyone, A few problems today with Plex today and LetsEncrypt.

 

Noticed this in my Letsencrypt container log. Anyone experienced anything similar? Nothings changed was working yesterday. Obviously references rate limits was wondering whether my network could have got confused/staled out a bit and that the container kept attempting to renew the cert and hit a rate limit or similar? Anyone had to fix anything similar?

 

Processing /etc/letsencrypt/renewal/removedmyrealone.co.uk.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cert is due for renewal, auto-renewing...
Plugins selected: Authenticator standalone, Installer None
Running pre-hook command: if ps aux | grep [n]ginx: > /dev/null; then s6-svc -d /var/run/s6/services/nginx; fi
Renewing an existing certificate
Attempting to renew cert (removedmyrealone.co.uk) from /etc/letsencrypt/renewal/removedmyrealone.co.uk.conf produced an unexpected error: urn:ietf:params:acme:error:rateLimited :: There were too many requests of a given type :: Error creating new order :: too many failed authorizations recently: see https://letsencrypt.org/docs/rate-limits/. Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/removedmyrealone/fullchain.pem (failure)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/removedmyrealone/fullchain.pem (failure)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Running post-hook command: if ps aux | grep 's6-supervise nginx' | grep -v grep > /dev/null; then s6-svc -u /var/run/s6/services/nginx; fi; cd /config/keys/letsencrypt && openssl pkcs12 -export -out privkey.pfx -inkey privkey.pem -in cert.pem -certfile chain.pem -passout pass: && cat {privkey,fullchain}.pem > priv-fullchain-bundle.pem
Hook command "if ps aux | grep 's6-supervise nginx' | grep -v grep > /dev/null; then s6-svc -u /var/run/s6/services/nginx; fi; cd /config/keys/letsencrypt && openssl pkcs12 -export -out privkey.pfx -inkey privkey.pem -in cert.pem -certfile chain.pem -passout pass: && cat {privkey,fullchain}.pem > priv-fullchain-bundle.pem" returned error code 1
Error output from if:
cat: {privkey,fullchain}.pem: No such file or directory

1 renew failure(s), 0 parse failure(s)
[cont-init.d] 50-config: exited 0.
[cont-init.d] done.
[services.d] starting services
[services.d] done.
nginx: [warn] could not build optimal proxy_headers_hash, you should increase either proxy_headers_hash_max_size: 512 or proxy_headers_hash_bucket_size: 64; ignoring proxy_headers_hash_bucket_size
nginx: [warn] could not build optimal proxy_headers_hash, you should increase either proxy_headers_hash_max_size: 512 or proxy_headers_hash_bucket_size: 64; ignoring proxy_headers_hash_bucket_size
Server ready

Edited by thestraycat
Link to comment
Hi everyone, A few problems today with Plex today and LetsEncrypt.
 
Noticed this in my Letsencrypt container log. Anyone experienced anything similar? Nothings changed was working yesterday. Obviously references rate limits was wondering whether my network could have got confused/staled out a bit and that the container kept attempting to renew the cert and hit a rate limit or similar? Anyone had to fix anything similar?
 
Processing /etc/letsencrypt/renewal/removedmyrealone.co.uk.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cert is due for renewal, auto-renewing...
Plugins selected: Authenticator standalone, Installer None
Running pre-hook command: if ps aux | grep [n]ginx: > /dev/null; then s6-svc -d /var/run/s6/services/nginx; fi
Renewing an existing certificate
Attempting to renew cert (removedmyrealone.co.uk) from /etc/letsencrypt/renewal/removedmyrealone.co.uk.conf produced an unexpected error: urn:ietf:params:acme:error:rateLimited :: There were too many requests of a given type :: Error creating new order :: too many failed authorizations recently: see https://letsencrypt.org/docs/rate-limits/. Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/removedmyrealone/fullchain.pem (failure)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/removedmyrealone/fullchain.pem (failure)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Running post-hook command: if ps aux | grep 's6-supervise nginx' | grep -v grep > /dev/null; then s6-svc -u /var/run/s6/services/nginx; fi; cd /config/keys/letsencrypt && openssl pkcs12 -export -out privkey.pfx -inkey privkey.pem -in cert.pem -certfile chain.pem -passout pass: && cat {privkey,fullchain}.pem > priv-fullchain-bundle.pem
Hook command "if ps aux | grep 's6-supervise nginx' | grep -v grep > /dev/null; then s6-svc -u /var/run/s6/services/nginx; fi; cd /config/keys/letsencrypt && openssl pkcs12 -export -out privkey.pfx -inkey privkey.pem -in cert.pem -certfile chain.pem -passout pass: && cat {privkey,fullchain}.pem > priv-fullchain-bundle.pem" returned error code 1
Error output from if:
cat: {privkey,fullchain}.pem: No such file or directory

1 renew failure(s), 0 parse failure(s)
[cont-init.d] 50-config: exited 0.
[cont-init.d] done.
[services.d] starting services
[services.d] done.
nginx: [warn] could not build optimal proxy_headers_hash, you should increase either proxy_headers_hash_max_size: 512 or proxy_headers_hash_bucket_size: 64; ignoring proxy_headers_hash_bucket_size
nginx: [warn] could not build optimal proxy_headers_hash, you should increase either proxy_headers_hash_max_size: 512 or proxy_headers_hash_bucket_size: 64; ignoring proxy_headers_hash_bucket_size
Server ready
I was reading a post that they had a hiccup earlier today. Maybe that's what you experience.

Sent from my BND-L34 using Tapatalk

Link to comment
6 hours ago, thestraycat said:

Do you think i'll all victim to the rate limit if my container has potentially spammed out to their server? I read the limit may not be reset for a week or so potentially? 

 

You should be able get around that specific limit by changing the subdomains

Link to comment
That's interesting. I was wondering if that was the case, as nothing had changed with my config, and the containers hadn't updated in the time window of the issue... Were you effected ijuarez and if so are you working now?
No but I read that and thought you might be affected

Sent from my BND-L34 using Tapatalk

Link to comment
On 7/21/2018 at 10:28 PM, aptalca said:

 

You read it and still ignored it the first time. I doubt putting it in the first post would make a difference. 

It would. Since it's critical information it should be posted in as many places as possible (repetition is not a bad thing in this place), not in the last paragraph of not even the main readme. 

 

I was following the "complete" guide that was recommended in this very forum and is the first google result of let'sencrypt + unraid and it makes absolutely no mention of this. This one:

https://cyanlabs.net/tutorials/the-complete-unraid-reverse-proxy-duck-dns-dynamic-dns-and-letsencrypt-guide/

 

It's very important for the less technically savvy (like myself) for all the steps to be consolidated into one place, which is why guides are my go to rather than the readmes of the application itself that won't go over setting up your dns or forwarding your ports because it's outside it's scope.  

 

I think the next video of spaceinvaderone will cover this very issue and honestly I can't wait. I found the "complete" guide pretty terrible since it skips a lot of crucial steps and stops before setting up any docker. They provide a default file to replace the one that comes with the container, but no explanation on how it was created and what each part is doing, no mentions of the steps required in the actual docker to get them to work. I know it's completely obvious to most of you to change the web path in say sonarr to /sonarr to get reverse proxy to work, but for someone following a step by step guide, it really isn't. I found that nugget of wisdom hidden away in the sample files for each docker (even though the readme says if you're using linuxserver dockers there's no need to change them, so there shouldn't be an expectation people are editing them).

 

TL;DR: Critical pieces of information required to get this thing to work scattered in many different readmes = bad. Consolidate everything with step by step instructions = good. Hopefully spaceinvaderone will save us soon.

 

PD: I used the default file from that guide and now even though I deleted the whole appdata folder and reinstalled the container every time I type https://192.160.0.11:444 it gets changed to https://192.160.0.11/htpc even though I don't have that container installed and of course it doesn't work. Do I need to reboot? 

Link to comment
5 hours ago, crazygambit said:

It would. Since it's critical information it should be posted in as many places as possible (repetition is not a bad thing in this place), not in the last paragraph of not even the main readme. 

 

I was following the "complete" guide that was recommended in this very forum and is the first google result of let'sencrypt + unraid and it makes absolutely no mention of this. This one:

https://cyanlabs.net/tutorials/the-complete-unraid-reverse-proxy-duck-dns-dynamic-dns-and-letsencrypt-guide/

 

It's very important for the less technically savvy (like myself) for all the steps to be consolidated into one place, which is why guides are my go to rather than the readmes of the application itself that won't go over setting up your dns or forwarding your ports because it's outside it's scope.  

 

I think the next video of spaceinvaderone will cover this very issue and honestly I can't wait. I found the "complete" guide pretty terrible since it skips a lot of crucial steps and stops before setting up any docker. They provide a default file to replace the one that comes with the container, but no explanation on how it was created and what each part is doing, no mentions of the steps required in the actual docker to get them to work. I know it's completely obvious to most of you to change the web path in say sonarr to /sonarr to get reverse proxy to work, but for someone following a step by step guide, it really isn't. I found that nugget of wisdom hidden away in the sample files for each docker (even though the readme says if you're using linuxserver dockers there's no need to change them, so there shouldn't be an expectation people are editing them).

 

TL;DR: Critical pieces of information required to get this thing to work scattered in many different readmes = bad. Consolidate everything with step by step instructions = good. Hopefully spaceinvaderone will save us soon.

 

PD: I used the default file from that guide and now even though I deleted the whole appdata folder and reinstalled the container every time I type https://192.160.0.11:444 it gets changed to https://192.160.0.11/htpc even though I don't have that container installed and of course it doesn't work. Do I need to reboot? 

 

What is critical information for you may not be as critical for someone else. Some people use this container to host a wordpress site, no reverse proxy needed. Some only reverse proxy. Some host a forum, some do all. Some run it on unraid, some on debian, some on rpi, some use portainer, some use docker compose and some use bash.

 

You keep asking for step by step instructions but given the vast number of scenarios this container can be used in and for, and the vast number of apps/guis you can reverse proxy, it is not possible to cater to all (not even the majority) users with a step by step guide. 

 

"Everything" in that readme is critical information. It is all up front and center. We are of the belief that we should teach folks how to use something and provide the tools, so they can adapt it to their needs rather than spoonfeed them some information and expect them to copy paste. Teach a man to fish and all. 

 

You already followed existing guides (by others) and weren't satisfied. You won't be satisfied with a guide unless it was written specifically for you, with your software and hardware environment in mind and with the exact apps you want to reverse proxy. 

 

I suggest you contact the authors of those guides and videos with your requests. 

 

With regards to your redirect issue, it may be browser caching of 301 redirects. Try a different browser/machine and if it works, clear the cache of the first browser. 

Link to comment

I understand why step by step instructions wouldn't be in the readmes, like I said it's out of their scope (which is why people like me prefer guides). I was talking more about your point of not putting that information in the first post and relying just on the manual. Like you said, this application has many uses and works on many OSs, but if I come to the unraid forums it's not unthinkable to expect the specific knowledge gathered in 89 pages of this thread to be summarized on the first post. You say it's unnecessary, but I strongly disagree. I understand if it can't be done by you and the developers on the container, but it's certainly something that could be done by the mods and experts in this thread. Setting this up for a normal user is actually pretty hard, it requires a lot of steps and failure in any of them can render it inoperable. Since a big selling point of unraid is the flexibility afforded by dockers one would think it would be a priority to make installing stuff like this as easy as possible. 

 

Also I love to learn how to do this stuff, which is why I found the third party guide so underwhelming, it just offered a premade default file with no explanation on how or why it was made. I think that's the reason spaceinvaderone's videos are so popular here. He explains the stuff pretty well and goes over every step without skipping stuff that's "too simple". When he makes his video on this topic it should be linked in the front page.

 

Thanks for your suggestion on the browser stuff, I'll do that.

Link to comment
7 minutes ago, crazygambit said:

I understand why step by step instructions wouldn't be in the readmes, like I said it's out of their scope (which is why people like me prefer guides). I was talking more about your point of not putting that information in the first post and relying just on the manual. Like you said, this application has many uses and works on many OSs, but if I come to the unraid forums it's not unthinkable to expect the specific knowledge gathered in 89 pages of this thread to be summarized on the first post. You say it's unnecessary, but I strongly disagree. I understand if it can't be done by you and the developers on the container, but it's certainly something that could be done by the mods and experts in this thread. Setting this up for a normal user is actually pretty hard, it requires a lot of steps and failure in any of them can render it inoperable. Since a big selling point of unraid is the flexibility afforded by dockers one would think it would be a priority to make installing stuff like this as easy as possible. 

 

Also I love to learn how to do this stuff, which is why I found the third party guide so underwhelming, it just offered a premade default file with no explanation on how or why it was made. I think that's the reason spaceinvaderone's videos are so popular here. He explains the stuff pretty well and goes over every step without skipping stuff that's "too simple". When he makes his video on this topic it should be linked in the front page.

 

Thanks for your suggestion on the browser stuff, I'll do that.

 

Give me one good reason why somebody else should wade through 89 pages of information to summarize it, because essentially you can't be bothered.  Why don't you contribute back and summarise it for the next person?

 

The mods and experts and anyone else you'd like to delegate this to are all volunteers.  Quite frankly we have 101 better things to do with our time than spoon feed you.

Link to comment
6 minutes ago, CHBMB said:

 

Give me one good reason why somebody else should wade through 89 pages of information to summarize it, because essentially you can't be bothered.  Why don't you contribute back and summarise it for the next person?

 

The mods and experts and anyone else you'd like to delegate this to are all volunteers.  Quite frankly we have 101 better things to do with our time than spoon feed you.

 

Because I don't understand it and I can't edit the first post, so there's little point in doing it if it's gonna be lost somewhere on a huge thread like this. Once I figure it out if you promise to put it in the first post so people can actually see it, I've got no problem doing it, though I fear it will be after spaceinvaderone releases his video (which should definitely be linked to in the first post IMO).

 

Edit: Also the fact that mods are volunteers is a Limetech decision and as a paying customer I really don't care one way or the other. This isn't a forum for some free open source project. It's a paid OS (and not cheap!), so I don't think expecting decent support is out of the question.

Edited by crazygambit
Link to comment
3 minutes ago, crazygambit said:

 

Because I don't understand it and I can't edit the first post, so there's little point in doing it if it's gonna be lost somewhere on a huge thread like this. Once I figure it out if you promise to put it in the first post so people can actually see it, I've got no problem doing it, though I fear it will be after spaceinvaderone releases his video (which should definitely be linked to in the first post IMO).

 

Edit: Also the fact that mods are volunteers is a Limetech decision and as a paying customer I really don't care one way or the other. This isn't a forum for some free open source project. It's a paid OS (and not cheap!), so I don't think expecting decent support is out of the question. 

 

You're not asking for support using LimeTech's application, you're asking for support using a volunteer developed free open source docker container.  That argument is null and void.  Every single one of linuxserver.io is a volunteer and unpaid, as is @gridrunner

 

The fact we use LimeTech's forums is immaterial. 

 

Also on the LimeTech front, you purchase the software, their support is a paid option, and quite frankly Unraid is very cheap for what you get.  Hell, been using my licence since 2011.

 

You summarise stuff, and I'll make sure it gets to the front page if it's any good.

Link to comment
18 minutes ago, crazygambit said:

I understand why step by step instructions wouldn't be in the readmes, like I said it's out of their scope (which is why people like me prefer guides). I was talking more about your point of not putting that information in the first post and relying just on the manual. Like you said, this application has many uses and works on many OSs, but if I come to the unraid forums it's not unthinkable to expect the specific knowledge gathered in 89 pages of this thread to be summarized on the first post. You say it's unnecessary, but I strongly disagree. I understand if it can't be done by you and the developers on the container, but it's certainly something that could be done by the mods and experts in this thread. Setting this up for a normal user is actually pretty hard, it requires a lot of steps and failure in any of them can render it inoperable. Since a big selling point of unraid is the flexibility afforded by dockers one would think it would be a priority to make installing stuff like this as easy as possible. 

 

Also I love to learn how to do this stuff, which is why I found the third party guide so underwhelming, it just offered a premade default file with no explanation on how or why it was made. I think that's the reason spaceinvaderone's videos are so popular here. He explains the stuff pretty well and goes over every step without skipping stuff that's "too simple". When he makes his video on this topic it should be linked in the front page.

 

Thanks for your suggestion on the browser stuff, I'll do that.

 

I'm not going to argue this any further.

 

The purpose of the first post in this thread is not to provide any instructions (it provides none, zero) but instead to provide links to the docs, the source and the images. The docs that are linked in the first post contain ALL of the information, they are platform agnostic and are kept up to date. They are the sole source of official info by the devs for ALL users, not just unraid. Putting instructions in the first post here would mean we have to keep info on multiple locations up to date.

 

So no, we are not going to add any instructions to the first post of this thread.

Link to comment

I have a question about security - I have NZBget, Radarr, Sonarr and Transmission all set with a username and password within each app which propmts with a small popup when accessing each site.  I also have Emby, Ombi and Nextcloud with nothing special other than the typical username and password selection default to each.  

 

Is this secure enough or should I still be using htpasswd?

Link to comment
I have a question about security - I have NZBget, Radarr, Sonarr and Transmission all set with a username and password within each app which propmts with a small popup when accessing each site.  I also have Emby, Ombi and Nextcloud with nothing special other than the typical username and password selection default to each.  
 
Is this secure enough or should I still be using htpasswd?
Same as what I do. Generally I try and use .htpasswd but for some services it just doesn't work well, such as those you've mentioned.

Sent from my Mi A1 using Tapatalk

  • Upvote 1
Link to comment
7 hours ago, CHBMB said:

Same as what I do. Generally I try and use .htpasswd but for some services it just doesn't work well, such as those you've mentioned.

Sent from my Mi A1 using Tapatalk
 

 

Completely unrelated to this topic, how do you like the Mi A1? (are you in the US, if so what carrier)

Link to comment
6 hours ago, ijuarez said:

 

Completely unrelated to this topic, how do you like the Mi A1? (are you in the US, if so what carrier)

 

I love it, I'm in the UK, so paid about £156 shipped from China for it (64GB version)  feels premium in the hand, monthly Android updates (last months to Android v8.1) Camera performs pretty well especially after enabling the google camera api.  Would definitely recommend it and would definitely consider another Chinese phone.

  • Like 1
Link to comment
1 hour ago, CHBMB said:

definitely consider another Chinese phone

 

I did win a chinese (domestic market) Huawei phone some time ago. This model isn't/wasn't available in NL and has nice features like 128MB and dual SIM.

Downside: you can't get completely rid of the chinese language. Some apps stay chinese whatever I try. Though I can see (but not understand) what music and movies are trendy in China :)

And once in a while when I press a wrong button, a nice lady tells me in chinese I am doing something stupid, other then that I love the phone.

 

Oh yeah, I had premium support the first year for quick repairs, but the nearest shop was 10000km away...

 

Edited by bonienl
Link to comment

I'm still trying to get to grips with this. One thing I don't understand is the benefits of having a custom bridge network. As far as I understand that's a feature from 6.5.1, so how was this done before then? Is there a downside in all dockers being "bridge" instead of "host"? I'd rather not make the change unless it's absolutely necessary or there are some big tangible advantages. Is it more secure? I've seen it on this thread that to access the unraid GUI a VPN is recommended since otherwise it's a huge security risk and that someone getting access to your dockers is not as bad, but if someone gets access to your sonarr and radarr they can literally delete your whole server in minutes, so if I get better security with a custom network I'd definitely go for that.

Link to comment
I'm still trying to get to grips with this. One thing I don't understand is the benefits of having a custom bridge network. As far as I understand that's a feature from 6.5.1, so how was this done before then? Is there a downside in all dockers being "bridge" instead of "host"? I'd rather not make the change unless it's absolutely necessary or there are some big tangible advantages. Is it more secure? I've seen it on this thread that to access the unraid GUI a VPN is recommended since otherwise it's a huge security risk and that someone getting access to your dockers is not as bad, but if someone gets access to your sonarr and radarr they can literally delete your whole server in minutes, so if I get better security with a custom network I'd definitely go for that.
I don't use a custom docker network, because I set mine up before it was in common use.

The advantage to it is that our preconfigured configs in the docker container work out the box, as they rely on the docker custom network for container name resolution to enable container to container networking rather than having to put an IP address in like I do.

If someone were to get access to a container they would have access to any of the volume mounts within that container irrespective of the type of docker network in use.

Which is kind of the whole point of putting stuff behind a Nginx reverse proxy, it gives me personally a lot more confidence in trusting a well developed open source project like Nginx than opening a port and relying on application X, Y or Z and their implementation of security.

Sent from my Mi A1 using Tapatalk

Link to comment

Docker host, bridge and macvlan are different network models available each with their own cons and pros. It depends on your requirements what suits best.

 

Host network

Pros: Containers have direct network access, just like any normal application. There is no overhead, and gives best network performance

Cons: Containers must use unique TCP/UDP ports each. Two containers using the same TCP/UDP port won't work

 

Bridge network

Pros: Allows TCP/UDP port translation and avoid conflicts when mutliple containers require the same TCP/UDP port

Cons: Uses NAT and not all applications can work with that properly. There is a performance penalty due to the address translation functionality

 

Macvlan network

Pros: Allows each container to use its own IP address and avoid TCP/UDP port conflicts. It is also well suited for network isolation, e.g. a separate network for Docker containers only

Cons: By security design the host (unRAID) can not communicate directly with containers in a macvlan network. There are solutions to overcome this restriction, but requires more network knowledge and proper support on your switch + router

 

Docker containers work in isolation, but it is the user who defines how well isolation is implementation.

 

Volume mapping is used to let containers access folders outside the container. The user must properly define which folder(s) and how these are accessed. Giving read-write access to a top folder (i.e /mnt or /mnt/user) with implied access to all its sub folders usually defeats the security purpose. Is read-write access required or can read-only do? Also, be more specific with mappings where possible, e.g. use /mnt/user/myshare/mysubfolder instead.

 

Network assignments tell who can talk to who. Putting all your containers as bridge or host may work well, but it implicitely allows containers to communicate with each other and unRAID. If more network security is desired then creating different networks, either bridge or macvlan, allows more network isolation. Only containers in the same network can communicate with each other, and by design containers can not communicate with unRAID on a macvlan network. In the event of a container breach, your server is still shielded.

 

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.