[Linux/Unix] [/Gurus/helpen/newbies]~# shutdown -r 65 [Deel 65]

quote:

Op maandag 20 juni 2016 11:17 schreef Aether het volgende:

twitter:

olesovhcom twitterde op zondag 19-06-2016 om 21:14:11 @ubuntu asks us to bill you 1e-2e per month for each VPS/PCI/PCC/SD. If not, prohibition to use the mark "Ubuntu" on our website. reageer retweet

[..]

Dit is de oprichter van OVH -- een hostingpartij in Frankrijk en qua grootte de nummer 1 in Europa.
Ubuntu vraagt sinds kort 1 ā 2 euro voor iedere server waar Ubuntu op geīnstalleerd is/wordt.

Ik lees wat anders. Ubuntu vraagt dat nu aan OVH, dus ze doen het nog niet. Ze willen dat OVH 1 tot 2 Euro gaat rekenen per VPS/PCI/PCC/SD, om het Ubuntu logo op hun site te mogen blijven voeren. Dat zijn dus kosten voor OVH, die ze -als het doorgaat- wel zullen doorberekenen.

quote:

Op maandag 20 juni 2016 11:17 schreef Aether het volgende:

twitter:

olesovhcom twitterde op zondag 19-06-2016 om 21:14:11 @ubuntu asks us to bill you 1e-2e per month for each VPS/PCI/PCC/SD. If not, prohibition to use the mark "Ubuntu" on our website. reageer retweet

[..]

Dit is de oprichter van OVH -- een hostingpartij in Frankrijk en qua grootte de nummer 1 in Europa.

ah duidelijk, was zelf ook al aan het zoeken, maar wist niet dat ze zo groot waren

quote:

Ubuntu vraagt sinds kort 1 ā 2 euro voor iedere server waar Ubuntu op geīnstalleerd is/wordt.

Maar als ik het goed begrijp kost het OVH dus geld om Ubuntu te gebruiken, daar kan ik op zich nog wel inkomen (en even overstappen naar een gratis alternatief zal een enorme investering zijn).

Maar waarom zou dat ook de klanten van hun weer ¤1,- ā ¤2,- kosten? Op 1 Ubuntu server kunnen toch meerdere dingen voor meerdere klanten gehost worden? (Ben nogal een noob qua servers en hosting etc. dus misschien dat ik domme aannames maak )

quote:

Op maandag 20 juni 2016 11:27 schreef Gehenna het volgende:
Maar waarom zou dat ook de klanten van hun weer ¤1,- ā ¤2,- kosten? Op 1 Ubuntu server kunnen toch meerdere dingen voor meerdere klanten gehost worden? (Ben nogal een noob qua servers en hosting etc. dus misschien dat ik domme aannames maak )

Het gaat over geld per VPS (virtuele server, één per klant), niet per hardwarematige server.

En verder gaat het heel duidelijk over doorberekenen aan de klant, dat staat er letterlijk:
"Ubuntu asks us to bill you 1e-2e per month", daar staat dus "Ubuntu vraagt ons ¤1 - ¤2 bij jullie in rekening te brengen".

quote:

Op maandag 20 juni 2016 11:32 schreef Aether het volgende:

[..]

Dat klopt. Ze vragen het sinds kort maar OVH rekent dat niet door. (Is überhaupt onduidelijk of Ubuntu het doorzet).

Ik vind het een vage zet, vooral de reden.

quote:

Op maandag 20 juni 2016 11:36 schreef Scarlet_Dragonfly het volgende:

[..]

Het gaat over geld per VPS (virtuele server, één per klant), niet per hardwarematige server.

En verder gaat het heel duidelijk over doorberekenen aan de klant, dat staat er letterlijk:
"Ubuntu asks us to bill you 1e-2e per month", daar staat dus "Ubuntu vraagt ons ¤1 - ¤2 bij jullie in rekening te brengen".

Ja snap ik, ik kan ook Engels Maar dat vond ik dus zo vreemd. Dat je als bedrijf dat aan een ander bedrijf vraagt..

Ah, er is een reden!

https://tweakers.net/nieu(...)merknaam-ubuntu.html

quote:

Op maandag 20 juni 2016 13:15 schreef Dubbeldrank het volgende:
Ah, er is een reden!

https://tweakers.net/nieu(...)merknaam-ubuntu.html

Kijk, dat verklaart een hoop! De update onderaan het bericht dus.
Toch weer jammer hoe zulk soort dingen eerst de wereld in geslingerd worden zonder achter de feitjes aan te gaan...
Lijkt me zoals het nu uitgelegd wordt heel redelijk wat Canonical in dit geval vraagt:

quote:

https://tweakers.net/nieu(...)merknaam-ubuntu.html

Update, 13.05: Zoals user Aaargh! aangeeft blijkt OVH de Ubuntu-distro aan te passen, met onder andere een gewijzigde kernel. In het handelsmerkbeleid van Canonical staat dat bedrijven in die gevallen goedkeuring van Canonical nodig hebben als ze het Ubuntu-merk gebruiken. Bovendien dienen ze in dat geval een licentieovereenkomst met mogelijk betaling te sluiten met Canonical.

quote:

Op maandag 20 juni 2016 13:44 schreef Scarlet_Dragonfly het volgende:

[..]

Kijk, dat verklaart een hoop! De update onderaan het bericht dus.
Toch weer jammer hoe zulk soort dingen eerst de wereld in geslingerd worden zonder achter de feitjes aan te gaan...
Lijkt me zoals het nu uitgelegd wordt heel redelijk wat Canonical in dit geval vraagt:

[..]

Precies, feitelijk breng je een aangepaste versie van een distro uit die je onder de vlag van Ubuntu adverteert. Dat kan natuulijk niet zomaar.

Ik ben niet helemaal newbie, maar hopelijk kan iemand mij hier toch een schop in de goede richting geven

De situatie is als volgt:

Ik draai thuis een server met daarop Debian. Op de server draai ik dmv QEMU (KVM) een virtuele server met daarop apache/mysql/php. Deze virtual server zit via een bridged netwerk verbonden aan mijn LAN.

Vanuit mijn LAN kan ik de apache server bereiken.

Op mijn router (KPN Experiabox v9) heb ik portforewarding aan staan naar zowel mijn fysieke server (alleen SSH) als naar de virtual server (alleen HTTPS). Dit heeft ruim een jaar uitstekend gedraaid, maar sinds kort werkt het niet meer: ik kan extern nog wel via SSH mijn fysieke server bereiken, maar de virtual server is tegenwoordig van buitenaf onbereikbaar.

"Sinds kort" is hier in ieder geval enkele dagen. Nou heb ik vorige week mijn server moeten herstarten (elektriciteit moest er af ivm vervangen meter), dus het zou in theorie kunnen dat ik ergens een netwerkinstelling niet goed heb opgeslagen. Ik zie echter niks vreemds.

Iemand een idee wat het probleem zou kunnen veroorzaken of waar ik moet zoeken??

(na een uurtje googlen op dit probleem kwam ik nog ergens tegen: "it might be that the router/switch upstream is blocking 'unauthorized switches' in the network", maar ik kan in mijn router niet een instelling vinden die daar op lijkt te duiden?)

quote:

Op maandag 20 juni 2016 22:22 schreef Ai_KaRaMBa het volgende:
Ik ben niet helemaal newbie, maar hopelijk kan iemand mij hier toch een schop in de goede richting geven

De situatie is als volgt:

Ik draai thuis een server met daarop Debian. Op de server draai ik dmv QEMU (KVM) een virtuele server met daarop apache/mysql/php. Deze virtual server zit via een bridged netwerk verbonden aan mijn LAN.

Vanuit mijn LAN kan ik de apache server bereiken.

Op mijn router (KPN Experiabox v9) heb ik portforewarding aan staan naar zowel mijn fysieke server (alleen SSH) als naar de virtual server (alleen HTTPS). Dit heeft ruim een jaar uitstekend gedraaid, maar sinds kort werkt het niet meer: ik kan extern nog wel via SSH mijn fysieke server bereiken, maar de virtual server is tegenwoordig van buitenaf onbereikbaar.

"Sinds kort" is hier in ieder geval enkele dagen. Nou heb ik vorige week mijn server moeten herstarten (elektriciteit moest er af ivm vervangen meter), dus het zou in theorie kunnen dat ik ergens een netwerkinstelling niet goed heb opgeslagen. Ik zie echter niks vreemds.

Iemand een idee wat het probleem zou kunnen veroorzaken of waar ik moet zoeken??

(na een uurtje googlen op dit probleem kwam ik nog ergens tegen: "it might be that the router/switch upstream is blocking 'unauthorized switches' in the network", maar ik kan in mijn router niet een instelling vinden die daar op lijkt te duiden?)

Eerst controleren of je virtual server nog aanstaat. valt dit op een manier te controleren SSH naar je externe server en daarin een tunnel maken naar je interne Virtual machine kijken of die aanstaat en of daar nog issues mee zijn en anders reboot van de virtual machine.

Of via je externe server je interne virtual server pingen en kijken ofje response krijgt.

quote:

Op dinsdag 21 juni 2016 15:54 schreef cablegunmaster het volgende:

[..]

Eerst controleren of je virtual server nog aanstaat. valt dit op een manier te controleren SSH naar je externe server en daarin een tunnel maken naar je interne Virtual machine kijken of die aanstaat en of daar nog issues mee zijn en anders reboot van de virtual machine.

Of via je externe server je interne virtual server pingen en kijken ofje response krijgt.

Zowel de fysieke server als de virtual server draaien nog prima (ook beide al een aantal keren gereset). Vanuit mijn LAN kan ik beide bereiken. Beide "servers" hebben een eigen IP adres op mijn LAN. Fysieke server draait op IP 192.168.2.20, virtual server heeft IP 192.168.2.50.

Op mijn router had ik twee port foreward rules gemaakt. SSH gaat naar 192.168.2.20 een HTTPS gaat naar 192.168.2.50. Voorheen werkte dat prima, maar nu dus niet meer.

Ook als ik de rules aanpas, door bijvoorbeeld de SSH foreward naar mijn virual server te sturen krijg ik vanuit extern geen verbinding meer. (is dus niet ergens een rare typo in de port foreward rule)

Trouwens: mijn router gebruik ik ook voor WiFi access, en ook draadloos verbinden met beide servers werkt prima. Ook de router kan dus verkeer naar beide apparaten krijgen.

Dus ondanks dat lokaal alles prima werkt, lijkt er toch ergens iets niet helemaal in orde met mijn bridge configuratie, waardoor NAT in de router de mist in gaat...

Zijn er specifieke stukken configuratie die handig zijn voor het foutzoeken, die ik moet delen?

quote:

Op dinsdag 21 juni 2016 16:53 schreef Ai_KaRaMBa het volgende:

[..]

Zowel de fysieke server als de virtual server draaien nog prima (ook beide al een aantal keren gereset). Vanuit mijn LAN kan ik beide bereiken. Beide "servers" hebben een eigen IP adres op mijn LAN. Fysieke server draait op IP 192.168.2.20, virtual server heeft IP 192.168.2.50.

Op mijn router had ik twee port foreward rules gemaakt. SSH gaat naar 192.168.2.20 een HTTPS gaat naar 192.168.2.50. Voorheen werkte dat prima, maar nu dus niet meer.

Ook als ik de rules aanpas, door bijvoorbeeld de SSH foreward naar mijn virual server te sturen krijg ik vanuit extern geen verbinding meer. (is dus niet ergens een rare typo in de port foreward rule)

Trouwens: mijn router gebruik ik ook voor WiFi access, en ook draadloos verbinden met beide servers werkt prima. Ook de router kan dus verkeer naar beide apparaten krijgen.

Dus ondanks dat lokaal alles prima werkt, lijkt er toch ergens iets niet helemaal in orde met mijn bridge configuratie, waardoor NAT in de router de mist in gaat...

Zijn er specifieke stukken configuratie die handig zijn voor het foutzoeken, die ik moet delen?

Beste idee is te testen of de poorten werken door een portscanner van extern door de lijn te laten.
Dit om te scannen of het openstaat voor de buitenwereld (want dat wil je uiteindelijk bereiken).
https://pentest-tools.com(...)-scanner-online-nmap

Gecheckt met NMAP: alle poorten die worden geforeward naar 192.168.2.20 (de fysieke server) staan op "open" en alle porten die worden geforeward naar 192.168.2.50 (de virtual server) staan op "filtered". Na omwisselen van de IP-adressen is het resultaat andersom.

Het lijkt erop dat de bridge interface op de fysieke server extern verkeer blokkeert (ik neem aan dat de router geen onderscheid maakt/kan maken)? Wat zou dat kunnen veroorzaken? Op zowel de fysieke server als de virtual server bevat de IPTABLES geen rules, en ook de routing tables lijken niks raars te bevatten.

quote:

Op dinsdag 21 juni 2016 20:46 schreef Ai_KaRaMBa het volgende:
Gecheckt met NMAP: alle poorten die worden geforeward naar 192.168.2.20 (de fysieke server) staan op "open" en alle porten die worden geforeward naar 192.168.2.50 (de virtual server) staan op "filtered". Na omwisselen van de IP-adressen is het resultaat andersom.

Het lijkt erop dat de bridge interface op de fysieke server extern verkeer blokkeert (ik neem aan dat de router geen onderscheid maakt/kan maken)? Wat zou dat kunnen veroorzaken? Op zowel de fysieke server als de virtual server bevat de IPTABLES geen rules, en ook de routing tables lijken niks raars te bevatten.

quote:

filtered
Nmap cannot determine whether the port is open because packet filtering prevents its probes from reaching the port. The filtering could be from a dedicated firewall device, router rules, or host-based firewall software. These ports frustrate attackers because they provide so little information. Sometimes they respond with ICMP error messages such as type 3 code 13 (destination unreachable: communication administratively prohibited), but filters that simply drop probes without responding are far more common. This forces Nmap to retry several times just in case the probe was dropped due to network congestion rather than filtering. This slows down the scan dramatically.

open|filtered
Nmap places ports in this state when it is unable to determine whether a port is open or filtered. This occurs for scan types in which open ports give no response. The lack of response could also mean that a packet filter dropped the probe or any response it elicited. So Nmap does not know for sure whether the port is open or being filtered. The UDP, IP protocol, FIN, NULL, and Xmas scans classify ports this way.

Bron:
https://nmap.org/book/man-port-scanning-basics.html

Iets zegt me dat er verschil zit tussen de opgegeven regels. ff posten perhaps?
Zit er een firewall op je virtual host perhaps?

quote:

Op dinsdag 21 juni 2016 21:25 schreef cablegunmaster het volgende:
Iets zegt me dat er verschil zit tussen de opgegeven regels. ff posten perhaps?
Zit er een firewall op je virtual host perhaps?

Welke regels wil je precies zien?

Voor zover ik weet heb ik geen firewall draaien op de virtual host; iptables -L geeft in ieder geval geen regels terug. Zowel de fysieke server als de virtual host draaien vrij kale debian wheezy installaties; komt debian nog met andere filters voorgeinstalleerd die ik over het hoofd zie?

quote:

Op maandag 20 juni 2016 13:15 schreef Dubbeldrank het volgende:
Ah, er is een reden!

https://tweakers.net/nieu(...)merknaam-ubuntu.html

Doen ze wel goed.

quote:

Op maandag 20 juni 2016 11:17 schreef Aether het volgende:

twitter:

olesovhcom twitterde op zondag 19-06-2016 om 21:14:11 @ubuntu asks us to bill you 1e-2e per month for each VPS/PCI/PCC/SD. If not, prohibition to use the mark "Ubuntu" on our website. reageer retweet

[..]

Dit is de oprichter van OVH -- een hostingpartij in Frankrijk en qua grootte de nummer 1 in Europa.
Ubuntu vraagt sinds kort 1 ā 2 euro voor iedere server waar Ubuntu op geīnstalleerd is/wordt.

quote:

Op maandag 20 juni 2016 11:26 schreef Dubbeldrank het volgende:

[..]

Ik lees wat anders. Ubuntu vraagt dat nu aan OVH, dus ze doen het nog niet. Ze willen dat OVH 1 tot 2 Euro gaat rekenen per VPS/PCI/PCC/SD, om het Ubuntu logo op hun site te mogen blijven voeren. Dat zijn dus kosten voor OVH, die ze -als het doorgaat- wel zullen doorberekenen.

Komt omdat ze de kernel aanpassen.
Dan heb je een licentie nodig.

Oh sorry dat was al bekend

quote:

Op zaterdag 25 juni 2016 00:50 schreef Aneurism het volgende:
Check eens hoe je net.ipv4.ip_forward staat? En of er ergens in je interface config forward uit staat?
Zou ook kunnen liggen aan forward table issues.

Op de host:


Aangezien het om een bridged configuratie gaat, neem ik aan dat forewarding inderdaad uit hoort te staan?

Forwarding (L3) moet je niet aan hebben staan in zo'n situatie idd, dat is gewoon de taak van de bridge (L2).

Al eens met tcpdump gespeeld, op zowel VM als host? Werkt ping heen en weer wel (en/of ARP - kan het MAC adres van je VM gevonden worden?)?

Hmm, waar wordt je eth0 aan je br0 interface toegevoegd? Ik denk dat dat het probleem is.

Mijn brug setup, vrij simpel:


Probeer eens "brctl addif br0 eth0" (of gewoon je cfg bijwerken).

[edit] Hrmm, hoewel, dan zou je hele inet verbinding niet werken lijkt me. Speel iig eens wat met brctl, zie of alle interfaces er wel op zitten enzo. Beetje wazig wat "bridge_ports all" dan doet. Ik zie het zo gauw ook niet gedocumenteerd.

[ Bericht 24% gewijzigd door LintuxCx op 27-06-2016 23:39:14 ]