Ok, ich bewerfe Dich einfach mal mit Links, die für Dich spannend sein könnten, wenn Du in die Richtung selbst etwas machen möchtest.
Wie Deine Lösung aussehen kann, wird aber stark von folgenden Fragen abhängen:
Wer ist Dein Zielpublikum? Erfahrene Unix-Admins? Entwickler? Anfänger ohne Shell-Kentnisse?
Wofür genau möchtest Du Dein Tool einsetzen? Provisioning? Betrieb und Wartung? Für sich häufig wiederholende Aufgaben mit wenig Variation? Anwendungs-Deployment?
Du wirst nicht alle Einsatzzwecke und auch nicht alle Zielgruppen mit einem Tool abdecken können, such Dir ein paar Use Cases aus und löse die gut, statt auf alles zu zielen und – zwangsläufig – zu scheitern.
Hier der schnelle ungeordnete Linkdump, vielleicht hilft Dir irgendwas davon weiter:
http://opscode.com/chef
https://github.com/duncs/clusterssh
http://www.canonical.com/enterprise-services/ubuntu-advantage/overview
http://rush.heroku.com/
http://docs.puppetlabs.com/mcollective/
http://docs.fabfile.org/en/1.0.0/index.html
https://fedorahosted.org/cobbler/
http://wiki.debian.org/DebianInstaller/Preseed
http://en.opensuse.org/Portal:YaST
http://www.syscp.org/
ich habe den code mal isoliert in ein separetes Programm kopiert, da funktioniert er...irgendwas blockiert im Haupt-programm scheinbar...aber keine Ahnung, wo und was...
ich könnte dir zwar den kompletten Code geben, aber ich denke, es ist zuviel verlangt, dass du mein Programm debuggst
Gruß Frank
EOutOfResources schrieb:
rüdiger schrieb:
sicher keine gute Idee
Schade.
Egal, dann wird es eben nicht cross-plattform...
Aber danke für deine Hilfe!
Nenene. Du solltest schon alles lesen, was ich geschrieben habe. So ein selektives Zitat ist natürlich blödsinnig. Wenn du unbedingt willst, dann geht es auch direkt mit dem X-Server. Aber das ist eine frickelei. Warum nimmst du nicht ein fertiges Toolkit?
Da wirds erklärt gibt auch noch ein paar andere nette Sachen da zum lernen...
http://www.codeproject.com/KB/debug/hardwarebreakpoint.aspx
http://www.codeproject.com/KB/security/AntiReverseEngineering.aspx
http://www.mp-hacks.de/forum/showthread.php?1761-Hardware-Breakpoints-und-M�glichkeiten
greetz Nukacola
Mo3bius schrieb:
Wenn WNOHANG angegeben wird, dann gibt waitpid 0 aus, wenn der Prozess läuft. Sobald der Prozess beendet wird gibt waitpid immer -1 aus.
waitpid gibt -1 beim Fehler aus(sollte nie passieren), und die pid, wenn der Prozess beendet wird. 0 wenn es keinen beendeten gefunden hat.
Mo3bius schrieb:
Waitpid (mit WNOHANG) wird sofort ausgeführt. Es wird also die nächste Anweisung angegangen. Ich habe nun über waitpid eine while-Schleife gelegt und frage ab, ob die SUmme aller noch laufenden Prozesse (also wo waitpid 0 ausgibt) > 0 ist. Ist dem so, so läuft mindestens noch ein Prozess.
Ja, waitpid mit WNOHANG kehrt sofort zurück, sodass weitergerechnet werden kann. Aber wenn waitpid = 0 zurückgibt, heißt das nur, dass es keinen Prozess mit geändertem Status (meistens dann beendet ) gefunden hat. Das heißt aber noch lange nicht, dass es noch Prozesse gibt.
Gast_Chris schrieb:
Offsets benutze ich keine, einer der Deskriptoren ist eine Pipe, also bliebe nur, dass man sockets nicht benutzen darf.
man page schrieb:
EBADF One or both file descriptors are not valid, or do not have proper read-write mode.
EINVAL Target file system doesn't support splicing; target file is opened in append mode; neither of the descriptors refers to a pipe; or offset given for nonseekable device.
ENOMEM Out of memory.
ESPIPE Either off_in or off_out was not NULL, but the corresponding file descriptor refers to a pipe.
Müsste da nicht eher ein EBADF kommen?
Dateisysteme unterstützen es seit .31 alle.
Die Datei wurde mit "w" geöffnet also nicht append.
Immer eine Pipe und nie Offsets.
Also gäbe es erstmal keinen Grund für EINVAL.
buffersize hat auch einen sinnvollen Wert?
Funktioniert es denn mit einem equivalenten tcp-socket?
Sonst geb mal ein Minimalbeispiel.
HeroHolger schrieb:
Diese mpp-Variablen sind leider etwas unglücklich gewählt und aufgebaut (man hätte es auch anders machen können als ein C-Feld auf nen Pointer auf nen Pointer.)
Allerdings sind sie m.E. syntaktisch vollständig und richtig und bisher hat valgrind diese Konstruke nie angemeckert in der Software.
aber, wie bekomme ich die Qt-Version heraus?
Hmm, solche Konstruktionen hatten wir in unseren Turbinenüberachungsprogrammen auch. Haben wir nach und nach durch Vektoren ersetzt. Pointer und C-Konstrukte machen in solchen Programmen immer wieder Ärger. Auf Valgrind würde ich hier auch nicht vertrauen, nach dem Ersatz durch die Vektoren sind nämlich of-by-one Fehlgriffe offensichtlich geworden. Valgrind neigt auch ein wenig zu Falsepositives. Ich würde den Quelltext auch noch mal an Cppcheck verfüttern (in Verbindung mit --enable=all) bekommt man da hin und wieder einen Aha-Effekt.
(in /MIL/RSN/DEV/RTS_HEAD/lib/Linux-glibc-GNU4-debug/libQtCore.so.4.6.0)
Da steht im Prinzip die Version, aber ob das jetzt ein direkter Pfad in das System ist oder nur eine Ausgabe von einer alten ld-Information ist, weiß ich nicht. Das müsstet ihr aber am besten wissen, ihr seid die Entwickler. In der Regel ist die originale Lib immer die libXXX.so mit mehreren Softlinks darauf. Sind meist 2 oder 3 Softlinks, einer mit der Majorversion, einer mit Major- und Minorversion und wenn der Installter (bzw die Distribution) gut war, noch einen weiteren Link mit Major-, Minor- und Bugfixversion. Das sind diese Nummern hinter dem *.so.
Also normalerweise sollte das gehen u.a. auf Solaris mit standard bash oder ksh oder anderen shells:
date > trallala
ls
more trallala
mit
declare
kann man sich die Umgebungsvariablen der Shell anschauen,
mit z.B.
echo $SHELL
welche Shell im Gange ist.
Hoi.
Ich suche nach einem eleganten Weg, in einem getracten Prozess einen Syscall auszuführen.
So ist mein Ansatz bis jetzt:
unsigned long Debugger::executeSyscall(
unsigned long code, std::vector<unsigned long> const& args) const
{
// Safe registers.
Registers buRegs = getRegisters(buRegs);
FpuRegisters buFregs = getFpuRegisters(buFregs);
// Get register set to modify.
Registers regs = buRegs;
#if __WORDSIZE == 32
// EAX stores the syscall code.
regs.eax = code;
// If less than 6 args exist, they are stored in registers.
size_t argCount = args.size();
if(argCount < 6)
{
while(argCount)
{
switch(argcount)
{
case 1:
regs.ebx = args[0];
break;
case 2:
regs.ecx = args[1];
break;
case 3:
regs.edx = args[2];
break;
case 4:
regs.esx = args[3];
break;
case 5:
regs.edi = args[4];
break;
}
--argCount;
}
}
// Otherwise we have to use memory.
else
{
// Get stack space.
regs.esp -= argCount * sizeof(unsigned long);
// Write arguments to stack.
for(size_t i = 0; i < argCount; ++i)
writeWord(regs.esp + i * sizeof(unsigned long), args[i]);
// EBX stores the address.
regs.ebx = regs.esp;
}
#elif __WORDSIZE == 64
...
#else
#error Unsupported platform !
#endif
writeWord/getRegs etc sind nur Wrapperfunktionen für ptrace mit entsprechenden Parametern.
Jetzt frag ich mich nur, wie ich möglichst elegant einen Softwareinterrupt ( INT 0x80 ) erzeugen kann.
Ja, ich weiß, die ganze Sache ist sehr hackish aber es wäre mir wichtig das hinzubekommen
Mein einziger Ansatz wäre es eine x-beliebige Page mit rwx-Rechten zu finden, einen INT 0x80 OP-Code zu schreiben, den EIP entsprechend anzupassen, und per PTRACE_SYSCALL abzuwarten bis der Syscall durch ist um dann den entsprechenden Speicher wiederherzustellen. Klingt für mich aber zu dirty.
Falls jemand irgendeine logische Idee hätte, bitte melden.
Grüße,
Ethon
Hi,
hat jemand eine idee (siehe vorheriger Post)?
außerdem hab ich festgestellt, dass nach der benutzung von execvp ein zombo-prozess zurückbleibt. wie kann ich das verhindern? muss ich das fork aufheben?
Gruß Frank
Wenn ich das compilierte Programm so starte,
/Programmpfad/Programmname -c /chrootpfad -e /zu_chrootendes_Programm -u 1006 -g 1006
bekomme ich von meiner errorausgabe in Zeile 183 die Ausgabe, dass das zu_chrootendes_Programm nicht existiert.
Aber meine Kontroll Ausgabe des neuen Wurzelvezeichnisses(Zeile 127) Listet das
zu_chrootendes_Programm mit auf.
Wenn ich mein programm ohne den Parameter zur setzen der Chroot Umgebung ausführe dann funktioniert es.
/Programmpfad/Programmname -e /chrootpfad/zu_chrootendes_Programm -u 1006 -g 1006
Also muss der fehler irgenwo beim chroot befehl(Zeile 107) oder beim exec befehl(Zeile 179) liegen.
Ich weiß wie man eine Chrootumgebung aufbaut mit dem Program Chroot bekomme ich auch die Programm darin gestartet,
aber ich muss es über mein Programm hinbekommen.
Habe auf SourceForge the3g-tools gefunden (in C geschrieben). Habe jetzt aber ein anderes Problem (Device locked - es läuft gleichzeitig wvdial). Danke für Hilfe - werde ich mir ansehen.
Schöne Grüße
ehh wo genau ist das linken?^^...
ich habs jetzt erstmal unter all geschrieben, dann machts keinen unterschied, also hab ichs mal hinter die zeile wo starcast steht geschrieben also:
all:
$(CC) -I. -c *.cpp -L/usr/lib/debug/usr/lib64
$(CC) -o Mesh2CASTS *.o $(LIBS)
$(CC) -o Mesh2HOMAT *.o $(LIBS)
$(CC) -o Mesh2STARCAST *.o $(LIBS) -static
jetzt kommt beim starten allerdings schon bei Eclipse ein Fehler.
**** Build of configuration Debug for project mesh2homat ****
make debug
g++ -I. -g -DDEBUG -c *.cpp -L/usr/lib/debug/usr/lib64
g++ -o Mesh2CASTS *.o -lboost_iostreams
g++ -o Mesh2HOMAT *.o -lboost_iostreams
g++ -o Mesh2STARCAST *.o -lboost_iostreams -static
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../lib64/libboost_iostreams.a(zlib.o): In function `boost::iostreams::detail::zlib_base::after(char const*&, char*&, bool)':
/usr/src/packages/BUILD/boost_1_36_0/libs/iostreams/src/zlib.cpp:123: undefined reference to `crc32'
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../lib64/libboost_iostreams.a(zlib.o): In function `boost::iostreams::detail::zlib_base::do_init(boost::iostreams::zlib_params const&, bool, void* (*)(void*, unsigned int, unsigned int), void (*)(void*, void*), void*)':
/usr/src/packages/BUILD/boost_1_36_0/libs/iostreams/src/zlib.cpp:184: undefined reference to `inflateInit2_'
/usr/src/packages/BUILD/boost_1_36_0/libs/iostreams/src/zlib.cpp:184: undefined reference to `deflateInit2_'
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../lib64/libboost_iostreams.a(zlib.o): In function `boost::iostreams::detail::zlib_base::reset(bool, bool)':
/usr/src/packages/BUILD/boost_1_36_0/libs/iostreams/src/zlib.cpp:150: undefined reference to `deflateReset'
/usr/src/packages/BUILD/boost_1_36_0/libs/iostreams/src/zlib.cpp:150: undefined reference to `inflateEnd'
/usr/src/packages/BUILD/boost_1_36_0/libs/iostreams/src/zlib.cpp:150: undefined reference to `inflateReset'
/usr/src/packages/BUILD/boost_1_36_0/libs/iostreams/src/zlib.cpp:150: undefined reference to `deflateEnd'
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../lib64/libboost_iostreams.a(zlib.o): In function `boost::iostreams::detail::zlib_base::inflate(int)':
/usr/src/packages/BUILD/boost_1_36_0/libs/iostreams/src/zlib.cpp:138: undefined reference to `inflate'
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../lib64/libboost_iostreams.a(zlib.o): In function `boost::iostreams::detail::zlib_base::deflate(int)':
/usr/src/packages/BUILD/boost_1_36_0/libs/iostreams/src/zlib.cpp:133: undefined reference to `deflate'
collect2: ld returned 1 exit status
make: *** [debug] Fehler 1
Hallo,
ich will per system () während der Laufzeit andere Programme aufrufen, gibt es da eine Möglichkeit, Fehlermeldungen die in der Shell ausgegeben werden, abzufangen und in meinem Progamm auszugeben?
Hallo,
ich programmiere unter Ubuntu, Maverick. Eine Funktion, die ich als Text-
Progress-Bar verwende, lautet:
inline
void progressBar(const string& s,unsigned ith,unsigned siz)
{
float fracDone=static_cast<float>(100*ith)/siz;
cout<<"\r "<<s<<":[ "<<fixed<<setprecision(2)<<setw(5)<<fracDone<<" % ] "<<flush<<setprecision(6);
cout.unsetf ( ios_base::floatfield );
}
Diese Funktion wird häufig aufgerufen, um die Progress-Bar zu aktualisieren.
Manchmal zu häufig, den zeitweise hört die Applikation für mehrere Sekunden
zu rechnen auf. In dieser Zeit geht die CPU-Auslastung auf Null zurück und
es erfolgt keine Ausgabe im (Gnome-)Terminal. Plötzlich läufts dann wieder.
Sicher, das Problem ist lösbar, indem man nicht so oft ausgibt, aber mich
würde doch interessieren, was da im System passiert. Läuft da irgendwo ein
Buffer voll?