Beiträge von Black Rider

Die Konsolenausgabe sieht soweit sauber aus. Das Ende z.B.:

Looking up breakpad interfaces from steamclient
Calling BreakpadMiniDumpSystemInit
Logging into anonymous gameserver account.
Connection to Steam servers successful.
   Public IP is 46.38.232.148.
Assigned anonymous gameserver Steam ID [A:1:2413597697(3588)].
VAC secure mode is activated.

Der Server ist nirgendwo zu finden. Wenn ich es direkt über die Konsole versuche, springt er aus dem aktuellen Spiel raus ins Hauptmenü, macht dann aber nichts mehr.

Edit:
Mein Fehler. Hatte in den iptables die DROP-Anweisungen, bevor ich die Steam-Ports freigeschalten hatte.

Ich habe bei mir einen CS:GO-Server mal testweise aufgesetzt, um mit ein paar Freunden zu spielen. Das ging relativ problemlos, woran es aber hapert, ist, dass man den Server im Spiel einfach nicht findet.

Er läuft ganz normal laut Konsole und auch der Port ist offen:

# nmap -sU 46.38.232.148




Starting Nmap 5.00 ( http://nmap.org ) at 2013-08-18 18:59 CEST
Interesting ports on kittblog.com (46.38.232.148):
Not shown: 994 closed ports
PORT      STATE         SERVICE
53/udp    open|filtered domain
68/udp    open|filtered dhcpc
111/udp   open|filtered rpcbind
123/udp   open|filtered ntp
5353/udp  open|filtered zeroconf
27015/udp open|filtered halflife




Nmap done: 1 IP address (1 host up) scanned in 1.38 seconds

Auch in den iptables sind die Ports freigegeben:

# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     udp  --  anywhere             anywhere            udp spts:27000:27030 dpts:1025:65355
ACCEPT     udp  --  anywhere             anywhere            udp spt:4380 dpts:1025:65355

Leider weiß ich hier nicht mehr weiter, woran es hakt bzw. was ich noch ändern könnte, weshalb ich hier auf Hilfe hoffe.

Wenn man beim Traffic-Filter seine IPv6-Adressen auswählt, werden keine Werte angezeigt.
Bei der Auflistung aller IP-Adressen stehen hier jedoch auch die richtigen Werte. Da scheint etwas nicht ganz so zu laufen, wie es soll.

Hast du denn auch die Berechtigungen dazu, die Dateien zu bearbeiten?
Was sagen denn die Logs von ProFTPd?

Mittlerweile hat sich einiges getan. So gab es eine Adressänderung von KittBlog.de auf KittBlog.com und eine Design- und Übersichtsänderung. Zudem wurden kostenlose Plugins und Stile in die Webdisk ausgelagert und ein Lexikon hinzugefügt, das für allerlei Kleinigkeiten genutzt wird.

Was genau alles geändert wurde, kann hier nachgelesen werden: Großes Update für KittBlog

Ich würde mich über weitere Meinungen, egal ob hier oder direkt auf KittBlog, sehr freuen!

Okay, danke für die Hilfe!

Das ist natürlich schade, aber danke für die Antwort

Gehe ich dann richtig in der Annahme, dass es auch über CIFS bzw. SMB nicht funktionieren würde?

Da Strato im Moment mit ihrer HiDrive das Angebot hat, 5 GB Speicher für nichts zu bekommen, dachte ich mir, ich probiere es mal aus.
Demzufolge wollte ich es als webDAV auf meinem Server einrichten, allerdings funktioniert das nicht so recht. davfs2 ist installiert, doch wenn ich das Ganze dann als Laufwerk mounten will, funktioniert es nicht. In der Konsole steht dann das:

root@v2201010XXXXXXXX:~# mount -t davfs https://webdav.hidrive.strato.com/ /mnt/webdav.XXXXX
Gib bitte den Benutzernamen für den Server https://webdav.hidrive.strato.com/ an; wenn du keinen angeben willst, drücke Return.
  Benutzername: XXXXX
Gib bitte das Passwort von XXXXX für den Server https://webdav.hidrive.strato.com/
an; wenn du keines angeben willst, drücke Return.
  Passwort:
/sbin/mount.davfs: kann die fuse-Gerätedatei nicht öffnen
/sbin/mount.davfs: ich versuche es mit dem Kernel-Dateisystem coda
/sbin/mount.davfs: keine freie coda-Gerätedatei gefunden
root@v2201010XXXXXXXX:~# FATAL: Could not load /lib/modules/2.6.36.4-vs2.3.0.36.39-netcup/modules.dep: No such file or directory
FATAL: Could not load /lib/modules/2.6.36.4-vs2.3.0.36.39-netcup/modules.dep: No such file or directory

Weiter macht die Konsole dann auch nach mehreren Minuten nicht.

Habe nochmals genau geschaut und ich muss mich entschuldigen, denn ich habe eine Falschaussage gemacht:
Das gesamte Update der Graphen dauert rund 5 Sekunden, nicht 5 Minuten. Dadurch kann das Problem eigentlich nicht an der Länge der Ausführung liegen.

Gibt es denn mittlerweile jemand, der eine bessere Strategie kennt?

Das habe ich schon gemacht, zumindest die Cronjobs. Der cronjob munin sieht demnach so aus:

#
# cron-jobs for munin
#




MAILTO=""




*/5 * * * *     munin if [ -x /usr/bin/munin-cron ]; then /usr/bin/munin-cron >>/var/log/cron.log >/dev/null 2>&1; fi
14 10 * * *     munin if [ -x /usr/share/munin/munin-limits ]; then /usr/share/munin/munin-limits --force --contact nagios --contact old-nagios >>/var/log/cron.log >/dev/null 2>&1; fi




*/5 * * * *     root for i in `mailq | egrep "^[0-9A-F]" | grep 'mail.kittblog.de' | cut -c1-12 | sed s/\*//g` ; do echo "delete msg: $i" ; /usr/sbin/postsuper -d $i ; done

Nicht wundern: Den letzten Befehl habe ich hinzugefügt, um die E-Mails automatisch aus der Queue zu löschen.

Der Cronjob von munin-node sieht so aus:

#
# cron-jobs for munin-node
#




MAILTO=""




# If the APT plugin is enabled, update packages databases approx. once
# an hour (12 invokations an hour, 1 in 12 chance that the update will
# happen), but ensure that there will never be more than two hour (7200
# seconds) interval between updates..
*/5 * * * *     root if [ -x /etc/munin/plugins/apt_all ]; then /etc/munin/plugins/apt_all update 7200 12  >>/var/log/cron.log >/dev/null 2>&1; elif [ -x /etc/munin/plugins/apt ]; then /etc/munin/plugins/apt update 7200 12  >>/var/log/cron.log >/dev/null 2>&1; fi

Somit sollte ja alles nach /dev/null umgeschrieben werden.

In der Tat. Er braucht laut munin-update.log etwa 5,05 -5,20 Minuten. Damit wäre die Problemursache geklärt und auch nicht weiter schlimm, wenn nicht jedes Mal eine E-Mail verschickt werden will. Wie kann ich das denn richtig abstellen?

Also die einzigen Cronjobs, die vorhanden sind, sind munin und munin-node unter /etc/cron.d. Weitere hinzugefügt habe ich hier nicht.

Die Lockdateien sind, wenn ich in den Ordner /tmp schaue, alle gelöscht. Wie könnte ich denn das Verzeichnis zu /var/lock ändern?

Ich bin es mal wieder mit Munin
Das Programm läuft nun einwandfrei, nur bekomme ich in der munin-update.log immer diese Meldung:

[FATAL ERROR] Lock already exists: /tmp/munin-update.lock. Dying.

Das Problem dabei ist nicht die Meldung selbst, die ist mir so ziemlich egal, da dennoch alles funktioniert.
Problematischer ist, dass Munin mir ständig eine E-Mail über diesen Fehler schicken will, wobei immer eine E-Mail-Adresse genutzt wird, die nicht zum Abschicken führt und so füllt sich stetig meine Mailqueue. Per Cronjob leere ich diese Einträge in der Queue zwar, dennoch ist es nervig.

Weiß vielleicht jemand, wie ich dieses Problem beheben oder einfach den Mail-Versand von Munin komplett abstellen kann?
In den Cronjobs habe ich schon den MAILTO-Eintrag entfernt und auch über crontab -e MAILTO="" eingetragen, doch das nützt nichts.

Habe das Bild mal extern hochgeladen. Irgendwie will es über die Dateianhangsfunktion nicht so recht funktionieren.

free -m bringt folgendes Ergebnis:

total       used       free     shared    buffers     cached
Mem:          1024       1006         17          0          0        850
-/+ buffers/cache:        156        867
Swap:         1024          0       1024

Edit:
Gehe ich richtig in der Annahme, dass der Rest, hier etwa 850 MB, einfach gecached sind?

Ich habe auf meinem vServer (Debian Squeeze) 1 GB RAM zur Verfügung und betreibe dort neben einem Apache Webserver einen MySQL-Server, einen FTP-Server mit proftpd sowie einen Mailserver mit Dovecot und Postfix. Des weiteren läuft noch Munin darauf und Memcached.

Nun habe ich das Problem, dass nach ein paar Tagen Uptime (etwa 2-3) mein RAM vollläuft. Laut dem Befehl top ist kein Arbeitsspeicher mehr frei.

Zum Test habe ich dann mal folgende Programme deaktiviert:
apache2
mysql
memcached
proftpd
dovecot

Im Grunde also alle, die ich selbst nutze (außer Munin, das hatte ich vergessen).

Aussehen tut danach top folgendermaßen:
[Blockierte Grafik: http://www.abload.de/thumb/topdqif.png]

Wie man erkennen kann, liegt der Verbrauch immer noch bei 830 MB, also habe ich gerade einmal ein Fünftel gewonnen.

Auch top selbst zeigt keinen Speicherfresser an, weshalb ich nun einmal euch fragen will, welches Programm denn so viel Speicher verbrauchen kann?

Du bist der Beste
Nach dem Neustarten des Crons zeigt mir Syslog mit deinem Befehl das an:

Jul  7 14:59:46 v220101071654175 /usr/sbin/cron[9170]: (CRON) INFO (pidfile fd = 3)
Jul  7 14:59:46 v220101071654175 /usr/sbin/cron[9171]: (CRON) STARTUP (fork ok)
Jul  7 14:59:46 v220101071654175 /usr/sbin/cron[9171]: (CRON) INFO (Running @reboot jobs)
Jul  7 15:00:01 v220101071654175 /USR/SBIN/CRON[10554]: (munin) CMD (if [ -x /usr/bin/munin-cron ]; then /usr/bin/munin-cron; fi)
Jul  7 15:00:01 v220101071654175 /USR/SBIN/CRON[10564]: (root) CMD (/usr/bin/php5 -q /var/www/froxlor/scripts/froxlor_master_cronjob.php)
Jul  7 15:00:01 v220101071654175 /USR/SBIN/CRON[10568]: (munin) CMD (  munin-cron)
Jul  7 15:05:01 v220101071654175 /USR/SBIN/CRON[18748]: (munin) CMD (  munin-cron)
Jul  7 15:05:01 v220101071654175 /USR/SBIN/CRON[18755]: (munin) CMD (if [ -x /usr/bin/munin-cron ]; then /usr/bin/munin-cron; fi)
Jul  7 15:05:01 v220101071654175 /USR/SBIN/CRON[18759]: (root) CMD (/usr/bin/php5 -q /var/www/froxlor/scripts/froxlor_master_cronjob.php)

Die Grafiken werden auch wieder erstellt und bisher (seit 20 Minuten) läuft alles!

Habe den Cronjob nur über crontab -e eingetragen, das habe ich gerade entfernt. Der Inhalt des originalen Cronjobs ist dieser:

#
# cron-jobs for munin
#




MAILTO=root




*/5 * * * *     munin if [ -x /usr/bin/munin-cron ]; then /usr/bin/munin-cron; fi
14 10 * * *     munin if [ -x /usr/share/munin/munin-limits ]; then /usr/share/munin/munin-limits --force --contact nagios --contact old-nagios; fi

Nutze Debian Squeeze

Also andere Cronjobs (z.B. Froxlor oder mein eigener Backup-Cronjob) laufen problemlos durch, zumindest bekomme ich da das Ergebnis, das ich möchte

Werde das aber mal mit deinem Befehl versuchen.

Edit:
Bekomme da dann folgende Meldung:

# update-rc.d cron defaults
update-rc.d: using dependency based boot sequencing
update-rc.d: warning: cron stop runlevel arguments (0 1 6) do not match LSB Default-Stop values (none)

Ja ich bin es mal wieder mit meinem allseits beliebten Thema Munin
Oder ist das Thema doch der Crontab? Ich weiß es selbst nicht so wirklich...

Also Munin habe ich ganz normal installiert

aptitude install munin munin-node munin-common

Funktioniert auch alles problemlos, die Konfigurationsdateien sind auf dem Standard nach der Installation.
Problem ist: Grafiken werden keine automatisch erstellt.

Logge ich mich als Benutzer munin ein und führe munin-check aus, erhalte ich nur zwei Meldungen:
Einmal gehört ein Ordner dem Benutzer munin und der Gruppe munin, wobei er nobody bzw. nogroup gehören soll. Also habe ich das eben geändert.
Des weiteren war der chmod für ein Plugin-Verzeichnis zu klein (700 statt 755), was ich auch geändert habe.

Daraufhin lies ich munin-update im debug-Modus laufen, wo mir dann einiges aufgefallen ist. Normal werden ja unter /var/run/munin entsprechende lock-Dateien erstellt, z.B. munin-update.lock. Laut debug und auch laut den Log-Dateien wird das gemacht, allerdings sind nach dem Ausführen keinerlei lock-Dateien vorhanden.
Einzig eine munin-node.pid ist in dem Ordner zu finden.

Führe ich den munin-cron manuell aus, funktioniert das Ganze wunderbar. Das mache ich mit diesem Befehl:

su munin -s /bin/bash -c 'time /usr/bin/munin-cron'

Also dachte ich, ich bin einfach mal schlau und setze diesen Befehl in einen crontab mit crontab -e und führe ihn alle 5 Minuten aus, das sollte das Problem beheben.
Allerdings tut sich da nichts, munin-cron wird per Cronjob einfach nicht ausgeführt, egal ob in der Standard-Version oder über meinen eigenen Befehl. Auch im syslog gibt es kein Anzeichen, dass der Cronjob ausgeführt wurde. Habe ihn testweise sogar auf jede Minute eingestellt, jedoch interessiert ihn das gar nicht.

Gebe ich den Befehl manuell in der Konsole ein, erscheint das:

su munin -s /bin/bash -c 'time /usr/bin/munin-cron'




real    0m3.341s
user    0m2.032s
sys     0m0.340s

Die Grafiken werden dabei aktualisiert, es funktioniert also problemlos.

Auch die Log-Dateien sagen dann nichts aus, hier z.B. ein aktueller Ausschnitt nach manuellem Ausführen aus der munin-html.log:

2011/07/07 11:45:39 Opened log file
2011/07/07 11:45:39 [INFO] Starting munin-html, getting lock /var/run/munin/munin-html.lock
2011/07/07 11:45:39 [INFO] Releasing lock file /var/run/munin/munin-html.lock
2011/07/07 11:45:39 [INFO] munin-html finished (0.27 sec)

Wie man sehen kann, wird also eine entsprechende lock-Datei geholt, es gibt dabei auch keinen Fehler, doch sie ist einfach nicht vorhanden...

Ich bin mit meinem Latein vollkommen am Ende und weiß nicht mehr, was ich tun soll, damit das funktioniert. Es wäre super, wenn mir jemand helfen könnte...
Falls weitere Informationen nötig sind, einfach fragen, ich liefere sie gerne