Fehler beim Kompilieren von proftpd

Vom einfachen Programm zum fertigen Debian-Paket, Fragen rund um Programmiersprachen, Scripting und Lizenzierung.
Antworten
feiaweng
Beiträge: 4
Registriert: 12.10.2006 13:20:51

Fehler beim Kompilieren von proftpd

Beitrag von feiaweng » 13.02.2013 13:03:18

Hallo Community,

vielleicht könnt ihr mir helfen.
Ich würde gerne clamav in proftpd integrieren, damit beim Upload auf Viren gescannt wird.
Mein System ist ein Debian 6.0 squeeze.
Im Repository sid gab es sogar ein Paket proftpd-mod-clamav. Das habe ich zu meinem bestehenden bereits installierten proftpd zusätzlich installiert.
Allerdings hatte ich zuvor nie ein Paket von sid installiert. Kurzum das Modul mod_clamav.so wird nicht geladen.
Funzt wohl nur, wenn man proftpd auch von sid installiert. Da es aber ein System ist, auf dem Kundendaten liegen, hab ich es wieder deinstalliert, das Paket proftpd-mod-clamav.
Habe dann versucht es mit folgender Anleitung zu patchen und zu bauen:
http://www.howtoforge.com/how-to-integr ... bian-lenny
Wenn ich das auf meinem Testsystem (vserver) mache, funktioniert das Paket bauen, allerdings macht der nur i386-Pakete.
Also habe ich versucht, auf meinem Rootserver

Code: Alles auswählen

Linux SERVERNAME 2.6.32-5-amd64 #1 SMP Sun May 6 04:00:17 UTC 2012 x86_64 GNU/Linux
das Paket zu bauen.
Beim Punkt in der Anleitung
dpkg-buildpackage kommt folgende Fehlermeldung

Code: Alles auswählen

server:/usr/src/proftpd-dfsg-1.3.3a# dpkg-buildpackage
dpkg-buildpackage: export CFLAGS from dpkg-buildflags (origin: vendor): -g -O2
dpkg-buildpackage: export CPPFLAGS from dpkg-buildflags (origin: vendor):
dpkg-buildpackage: export CXXFLAGS from dpkg-buildflags (origin: vendor): -g -O2
dpkg-buildpackage: export FFLAGS from dpkg-buildflags (origin: vendor): -g -O2
dpkg-buildpackage: export LDFLAGS from dpkg-buildflags (origin: vendor):
dpkg-buildpackage: source package proftpd-dfsg
dpkg-buildpackage: source version 1.3.3a-6squeeze6
dpkg-buildpackage: source changed by Francesco Paolo Lovergine <frankie@debian.org>
dpkg-buildpackage: host architecture amd64
 dpkg-source --before-build proftpd-dfsg-1.3.3a
dpkg-checkbuilddeps: Unmet build dependencies: libacl1-dev libattr1-dev
dpkg-buildpackage: warning: Build dependencies/conflicts unsatisfied; aborting.
dpkg-buildpackage: warning: (Use -d flag to override.)
Mache ich das mit der -d Option, dann klappt es. Allerdings weiß ich nicht, ob dann die Pakete in Ordnung sind. Ich möchte die nicht einfach so installieren, weil ich nicht weiß, ob die ok sind, wegen des Fehlers.
Möchte ich mit apt-get libacl1-dev installieren (apt-get install libacl1) kommt folgendes:

Code: Alles auswählen

The following packages have unmet dependencies:
 libacl1-dev : Depends: libacl1 (= 2.2.49-4) but 2.2.51-8 is to be installed
               Depends: libattr1-dev (>= 2.4.4) but it is not going to be installed
Muss ich das ernst nehmen, oder ist derjenige, der die binaries mit den require-optionen gefüllt hat, nur übervorsichtig?
Was mich auch verwundert ist, der vserver ist auch ein Debian squeeze, trotzdem baut er nur i386 Pakete.
Hier uname -a

Code: Alles auswählen

Linux VSERVERNAME 2.6.33.2 #3 SMP Wed Apr 21 10:14:32 CEST 2010 x86_64 GNU/Linux
Hat jemand einen Tipp für mich?

Danke und Gruss
feiaweng

syssi
Beiträge: 2951
Registriert: 24.12.2010 16:50:59
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Rheinland

Re: Fehler beim Kompilieren von proftpd

Beitrag von syssi » 13.02.2013 13:17:24

Wenn du die Option "-d" benutzt und damit die beiden Abhaengigkeiten zur Compile-Zeit nicht vorhanden sind, so wird die Unterstuetzung von dieses Feature (ACLs) einfach deaktiviert. Nun musst du entscheiden, ob du in deinem System ACLs einsetzt und ob du nicht vielleicht doch einen proftpd mit ACL-Unterstützung bauen möchtest.

Frag mal dein System (Userland), mit welcher Architektur es laeuft: dpkg-architecture -qDEB_HOST_ARCH

Ich vermute, dass es "i386" zurueck gibt. Folglich nutzt du einen 64bit Kernel (auf einer 64bit faehigen CPU) und hast ein 32bit System (Userland) installiert. Sowas ist grundsaetzlich moeglich und nicht schlimm. Eine 32bit Anwendung kann damit lediglich max. 2GB Speicher allozieren. Insgesamt kann der Kernel aber mehr als 2GB verwalten und unterschiedlichen Anwendungen im Userland zur Verfuegung stellen.

Gruss syssi

feiaweng
Beiträge: 4
Registriert: 12.10.2006 13:20:51

Re: Fehler beim Kompilieren von proftpd

Beitrag von feiaweng » 13.02.2013 13:26:55

Hallo syssi,

ich habe 2 Server.
Einmal einen vserver , das ist mein Testserver. Der gibt bei dem Befehl

Code: Alles auswählen

dpkg-architecture -qDEB_HOST_ARCH "i386" zurück
Und mein Rootserver, das ist mein Livesystem. Der gibt bei dem Befehl

Code: Alles auswählen

dpkg-architecture -qDEB_HOST_ARCH "amd64" zurück
Mein Server hat auch 8 GB RAM.
Wenn du mit ACLs, setfacl und getfacl meinst, die habe ich auf meinen Server nicht installiert.
Benutze nur Standardberechtigungen, und die proftpd-Rechte sind in der mysql-db gesetzt.
Mein proftpd läuft mit mysql.
Kann ich also die libacl- Errors dann ignorieren?

Gruss feiaweng

syssi
Beiträge: 2951
Registriert: 24.12.2010 16:50:59
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Rheinland

Re: Fehler beim Kompilieren von proftpd

Beitrag von syssi » 13.02.2013 13:33:09

Dann betreibst du ein 64bit und ein 32bit Userland, je nach Server. ;-)

ACLs sind ein Feature deines Dateisystems. Wenn du diesem Feature noch nie Aufmerksamkeit geschenkt hast, dann wirst du es fuer den Betrieb deines FTP-Servers auch nicht nutzen und kannst es getrost ignorieren.

Scheinbar hast du irgendwann mal "squeeze" und "wheezy" auf deinem V-Server gemischt. Moeglicherweise wuerde ein

Code: Alles auswählen

apt-get -t squeeze install libacl1-dev libacl1 libattr1-dev
zum Ziel fuehren. Vorausgesetzt keine anderen Anwendungen aus Wheery erwarten diese Bibliotheken in aktuell.

feiaweng
Beiträge: 4
Registriert: 12.10.2006 13:20:51

Re: Fehler beim Kompilieren von proftpd

Beitrag von feiaweng » 13.02.2013 14:22:51

Danke,

ich benötige keine ACLs. Daher ignorier ich die Errors, und probier mal das Installiefen.
Auf dem vserver hatte ich lenny upgedatet, daher vielleicht das 32 bit Userland.
Danke nochmal für die Info.

Gruß feiaweng

Antworten