[0 packets dropped by kernel]

sysctrl net.inet.ip.fw.one_pass
kldstat
А с какво натиш  понеже в рц-то нямаш извикани pf/ipf/ipfw_nat ?!

Код

GeSHi (Bash):
# sysctl net.inet.ip.fw.one_pass
net.inet.ip.fw.one_pass: 1
 
 # kldstat
Id Refs Address    Size     Name
 1   13 0xc0400000 147e6d0  kernel
 2    1 0xc8336000 4a000    linux.ko
 3    1 0xc8519000 5000     if_tap.ko
 4    1 0xc8523000 a000     if_bridge.ko
 5    1 0xc8536000 6000     bridgestp.ko

За натенето... дори не се бях замислял. Имам описани на две места в конфиг файлове нат-а. Единия е за pppoe връзките (едното ISP), другите са в natd.conf-ига (2рото ISP)

Код

GeSHi (Bash):
#cat /custom/natd/natd.conf
use_sockets yes
same_ports yes
dynamic yes
log no
redirect_port tcp 192.168.1.25:1723 1723 # vpn
redirect_port udp 192.168.1.25:1723 1723 # vpn
redirect_port tcp 192.168.1.25:80 8000 #site1
...........
...........
...........
 
# cat /etc/ppp/ppp.conf
default:
    set log Phase Chat LCP IPCP CCP tun command
    nat enable yes
    nat same_ports yes
    nat use_sockets yes
 
#########################################################################
### READ ME FIRST!!!!
###
###
###
########################################################################
    nat port tcp 192.168.1.25:1723 1723    #VPN
    nat port udp 192.168.1.25:1723 1723    #VPN
    nat port tcp 192.168.1.45:3306 45330    #DB

Другото което супер много ме дразни и нещо не намирам инфо в google, е защо tcpdump винаги ми дава

0 packets dropped by kernel

Пускам да си дъмпя за да видя какво се случва и дали ipfw правило работи, но никакъв трафик не се вижда. Трябва да разреша през ipfw въпросния трафик и тогава tcpdump да започне да "вижда" пакетите. В 7.0 нямаше никакъв проблем да си виждам реджекнатите пакети и така да знам къде е проблема.

Нещо съм пропуснал при компилирането на кърнела ли (не съм спирал нищо уж, само добавих) или другаде е проблема?

да нормално е да не го намериш /proc/mdstat е това което исках да видя.

Код

GeSHi (Bash):
# cat /proc/mdstat
Personalities : [raid1]
md127 : active raid1 sda[0]
      1953511424 blocks super external:/md0/0 [2/1] [U_]
 
md0 : inactive sda[0](S)
      3028 blocks super external:imsm
 
unused devices: <none>

Дай изхода от df -h и cat /proc/mdadm и blkid

Намерих няколко извадки с подобни проблеми които могат да ти бъдат полезни:
https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/964052
https://bugzilla.redhat.com/show_bug.cgi?id=606481

Това което мисля че трябва да направиш е описано тук:
https://aubreykloppers.wordpress.com/2012/07/06/mdadm-devmd127/
Или с други думи редактираш mdadm.conf с правилния раид (/dev/md0 с UUID 392de428:b7cb9135:70102f5b:d9e480b4) след като направиш копие на файла и генерираш нов инитрамфс. Интересно е дали ще сработи ако генерираш нов инитрамфс без да пипаш mdadm.conf но нищо не ти пречи да пробваш и по двата начина - вече имаш копия и на конфигурационния файл и на инитрамфс.

Дай изхода от командите за сравнение и действай, не виждам друг начин.
Междудругото имал ли си някакви ъпдейти/ъпгрейди по време на проблема, които могат да генерират нов инитрамфс, като ъпдейт на кърнел например?

Код

GeSHi (Bash):
# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/md127p2           15G   11G  3.0G  79% /
tmpfs                 753M     0  753M   0% /dev/shm
/dev/md127p1          485M   53M  407M  12% /boot
/dev/md127p6          1.8T  1.5T  288G  84% /opt
/dev/md127p3          3.9G  185M  3.5G   5% /var/log

Не мога да намеря cat /proc/mdadm. Имам само .conf-а и bin-а на mdadm.

Код

GeSHi (Bash):
# blkid
/dev/md127p2: UUID="14ef63e6-e198-42cd-a496-a28929ea7760" TYPE="ext4"
/dev/md127p1: UUID="7313284f-2b2c-49ce-8514-4f71eda8af73" TYPE="ext4"
/dev/md127p3: UUID="e3a37d6f-b26f-4793-897b-f9e51c355c02" TYPE="ext4"
/dev/md127p5: UUID="940789ed-16c6-46da-8493-b20b9db0f05f" TYPE="swap"
/dev/md127p6: UUID="24744a78-4010-417a-967a-55b8d4a7caad" TYPE="ext4"

Не, не са правени никакви ъпдейти/ъпгрейди. Просто един ден намерих харда с умряла механика.

NAT имаш ли ?
Катни rc.conf и  sysctl.conf.

Да, имам NAT.

Код

GeSHi ():
# cat /etc/sysctl.conf
 
# $FreeBSD: releng/10.1/etc/sysctl.conf 112200 2003-03-13 18:43:50Z mux $
#
#  This file is read when going to multi-user and its contents piped thru
#  ``sysctl'' to adjust kernel values.  ``man 5 sysctl.conf'' for details.
#
 
# Uncomment this to prevent users from seeing information about processes that
# are being run under another UID.
#security.bsd.see_other_uids=0
 
 
#cat /etc/rc.conf
 
gateway_enable="YES"
hostname="myhostname"
ifconfig_le2_name="le3"
ifconfig_le1="inet 192.168.1.1 netmask 255.255.255.0"
ifconfig_le3="inet 95.158.*.* netmask 255.255.255.252"
keymap="bg.phonetic.ctrlcaps"
linux_enable="YES"
sshd_enable="YES"
snmpd_enable="YES"
ntpd_enable="YES"
ntpd_flags="-g"
sendmail_enable="NO"
sendmail_submit_enable="YES" #to NO
 
#PPPoE
network_interfaces="auto"
ifconfig_le0="inet 192.168.15.1 netmask 255.255.255.0 -arp up"
ppp_enable="YES"
ppp_mode="background"
ppp_profile="pppoe"
 
#OpenVPN
openvpn_enable="YES"
openvpn_configfile="/usr/local/etc/openvpn/mynetwork"
openvpn_if="tun"
openvpn_if="tap bridge"
 
arpwatch_interface="le1"
moused_enable="YES"
 
#snmp
snmpd_enable="YES"
snmpd_flags="-a"
snmpd_conffile="/usr/local/share/snmp/snmpd.conf /etc/snmpd.config"
snmptrapd_enable="YES"
snmptrapd_flags="-a -p /var/run/snmptrapd.pid"
 

Значи същата работа. Имал си мд0 но сега имаш мд127, а мд0 е грешен.
 Опитай да махнеш новия диск и виж дали ще запали с мд127 или с мд0 с един дегрейдет диск. Според мдадм мд0 е с два spare диска /dev/sda и /dev/sdb което е грешно. Опитай се да върнеш старото положение. Махай новия диск и ребутвай само със стария. Надявам се да можеш да си направиш бекъп на важните неща в случай че нещо се сбози. В случай че запали постни пак изхода от командите които ти поисках. Можеш и изхода от mdadm --examine --scan да сравниш с това което е в mdadm.conf. Не забравяй че dracut -f може да ти бъде от полза за да генерираш правилният инитрамфс имидж. И не забравяй за копие на стария инитрамфс

За момента направих копие на initramfs и разкачих 2рия диск. Ето резултата от командите:

Код

GeSHi ():
# fdisk -l
 
Disk /dev/sda: 2000.4 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x0002dbe5
 
   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          64      512000   83  Linux
Partition 1 does not end on cylinder boundary.
/dev/sda2              64        1977    15360000   83  Linux
/dev/sda3            1977        2487     4096000   83  Linux
/dev/sda4            2487      243201  1933542400    5  Extended
/dev/sda5            2487        2742     2048000   82  Linux swap / Solaris
/dev/sda6            2742      243201  1931492352   83  Linux
 
Disk /dev/md127: 2000.4 GB, 2000395698176 bytes
2 heads, 4 sectors/track, 488377856 cylinders
Units = cylinders of 8 * 512 = 4096 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x0002dbe5
 
      Device Boot      Start         End      Blocks   Id  System
/dev/md127p1   *         257      128256      512000   83  Linux
Partition 1 does not end on cylinder boundary.
/dev/md127p2          128257     3968256    15360000   83  Linux
Partition 2 does not end on cylinder boundary.
/dev/md127p3         3968257     4992256     4096000   83  Linux
Partition 3 does not end on cylinder boundary.
/dev/md127p4         4992257   488377856  1933542400    5  Extended
Partition 4 does not end on cylinder boundary.
/dev/md127p5         4992513     5504512     2048000   82  Linux swap / Solaris
/dev/md127p6         5504769   488377856  1931492352   83  Linux
 
# cat /etc/mdadm.conf
# mdadm.conf written out by anaconda
MAILADDR root
AUTO +imsm +1.x -all
ARRAY /dev/md0 UUID=392de428:b7cb9135:70102f5b:d9e480b4
ARRAY /dev/md127 UUID=202f047f:650f7c87:050db2d8:98969446
 
# mdadm --detail --scan
ARRAY /dev/md0 metadata=imsm UUID=392de428:b7cb9135:70102f5b:d9e480b4
ARRAY /dev/md/Volume0 container=/dev/md0 member=0 UUID=202f047f:650f7c87:050db2d8:98969446
 
 
# mdadm -Q -D /dev/md0
/dev/md0:
        Version : imsm
     Raid Level : container
  Total Devices : 1
 
Working Devices : 1
 
 
           UUID : 392de428:b7cb9135:70102f5b:d9e480b4
  Member Arrays : /dev/md/Volume0
 
    Number   Major   Minor   RaidDevice
 
       0       8        0        -        /dev/sda
 
 

Не знам дали ми се струва или има разлика между mdadm.conf и детайл скана. Еднаквото UUID ме обърка тотално

Значи че / ти е md0...не е просто /home примерно?

Ако успееш да подкараш машината с здравия диск дори и дегрейдед ще започнеш от началото на процедурата.
Пиши какво се случва.

Всъщност е md127*

Код

GeSHi ():
#df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/md127p2           15G   11G  3.0G  79% /
tmpfs                 753M     0  753M   0% /dev/shm
/dev/md127p1          485M   37M  423M   9% /boot
/dev/md127p6          1.8T  1.4T  337G  81% /opt
/dev/md127p3          3.9G  184M  3.5G   5% /var/log

Доколкото виждам разположението на mdadm.conf и "# mdadm.conf written out by anaconda" ти не ползваш Debian/ubuntu, следователно update-initramfs -u е dracut -f което ще презапише текущия но преди това направи копие на /boot/initramfs-$(uname -r).img.
Проблема е че в момента активния раид е md127. Хубаво е да погледнеш и UUID-то (blkid) с това в /etc/fstab. Предполагам че новия диск си го hot plug-нал и това което бих направил (след задължителен бекъп) е следното. Махам новия диск виждаме какво се случва с раидовете, евентуален reboot в който бих очаквал машината да boot-не с degraded раид (както е било когато се е счупил диска) след което стандартната процедура с фейлване на диска махане от масива и добавяне на новият диск.
Въпроса е че ще трябва да си поиграеш и рискуваш. С новият initrd/initramfs това което ще се случи е да ъпдейтнеш конфигурацията на /etc/mdadm.conf в самият initrd, но тва трябва да се случи след като сме сигурни че масивът е правилно намерен и конфигурирани, дори и деградирал а в твоят случай не изглежда така, защото ти трябва да имаш един, а реално машината вижда 2.
Аз бих постъпил по този начин за да опитам да получа старата ситуация с md0 и един диск. Въпроса е че ако машината не буут-не след рестарт ще се наложи в single user mode да опитваш да assemble-ваш раида с единия диск и вероятно тогава да update-неш initrd за да буутнеш с дегрейдед раид. Но всичко това са предположения.
Както казваше бивш колега: "Трябва да счупиш няколко раида, за да се научиш да ги оправяш"
Успех!

Мерси за напътствията. Ето малко повече инфо от ръчкането от преди дни.
След като махнах проблемния хард, опитах да го маркирам фейл с:

Код:

mdadm --manage /dev/md0 --fail /dev/sdb*

, но аз така или иначе вече го бях свалил и просто sdb не съществуваше и ми даваше грешна команда.
След доооста четене и пробване на кажи-речи какво ли не, след като уж RAID-а тръгна да се билдва и нищо не стана след зареждането в /proc/mdstat , реших да рестартирам машината. По закона на Мърфи, тя не буутна и даде грешка във файловата система. След няколко fsck-а в сингъл мод, уж се оправи, но аз разкачих 2рия диск, защото си мислех да не би нещо от него да идва проблема след билдването на райда.
Разкачих и  2ри хард за тест, машината тръгна. После я спрях и пак закачих харда.
Сега ще погледна тези неща които си казал.

Най-накрая ъпдейтнах проблемната машина (дузина теми за нея в този раздел) и се сблъсках с нещо странно.
Имам няколко интерфейса и задавам с in и out от къде да минава трафика за дадено IP/vlan. До момента с 7ма версия на FreeBSD правилото работи, а сега вече не. Става дума за нещо много елементарно от рода на:

ipfw add 1 allow all from 192.168.1.2 to any out via 212.212.212.212

Опитах да сменя  212.212.212.212 с името на интерфейса (le1), но без успех. ipfw show показва, че има трафик, но не се отварят страници.

Търсих в google за някакви промени по синтаксис на ipfw в новите версии на FreeBSD, но пак греда.

[mdadm.conf]

Можеш ли да постнеш и mdadm.conf-а?
Извинявай но гадая малко....трябва да имаш само md0 и ако схващам правилно sdb се е счупил и след смяната му sda е активен в md127 а двата sda и sdb са маркирани като Spare (S) в  md0...

Намерих някаква старичка тема, която ми се приближава до твоя случай, но както казвам...гадая и съм объркан.....и съм виждал как се синква изпаднал диск за 5 дни от масив (raid1) върху активния в масива на production система . Не искам да те подвеждам с предположения.

Първо мерси за помоща. Както казах, няма проблем за всякакви догадки и предположение, защото ме измъчи тоя райд. Така като чета изглежда точно както го описваш. Ето конфига:

Код

GeSHi ():
# cat /etc/mdadm.conf
# mdadm.conf written out by anaconda
MAILADDR root
AUTO +imsm +1.x -all
ARRAY /dev/md0 UUID=392de428:b7cb9135:70102f5b:d9e480b4
ARRAY /dev/md127 UUID=202f047f:650f7c87:050db2d8:98969446

Код

GeSHi ():
# ls /dev/md/
autorebuild.pid  md-device-map    Volume0p2        Volume0p5
md0.pid          Volume0          Volume0p3        Volume0p6
md0.sock         Volume0p1        Volume0p4

Ако правилно съм разбрал от линка, редактирам mdadm.conf, като оставям само md0 и стартирам update-initramfs -u

Можеш ли да дадеш информация от:

Код:

mdadm -Q -D /dev/md0

По спомен, мисля че това което виждам е така наречения split brain.

Edit:
Прегледай този скрипт:
https://github.com/dobber/md-split

Да, разбира се:

Код

GeSHi ():
# mdadm -Q -D /dev/md0
/dev/md0:
        Version : imsm
     Raid Level : container
  Total Devices : 2
 
Working Devices : 2
 
 
           UUID : 392de428:b7cb9135:70102f5b:d9e480b4
  Member Arrays : /dev/md/Volume0
 
    Number   Major   Minor   RaidDevice
 
       0       8       16        -        /dev/sdb
       1       8        0        -        /dev/sda
 

Ето ти:

Код

GeSHi ():
# mdadm -Q -D /dev/md127
/dev/md127:
      Container : /dev/md0, member 0
     Raid Level : raid1
     Array Size : 1953511424 (1863.01 GiB 2000.40 GB)
  Used Dev Size : 1953511556 (1863.01 GiB 2000.40 GB)
   Raid Devices : 2
  Total Devices : 1
 
          State : clean, degraded
 Active Devices : 1
Working Devices : 1
 Failed Devices : 0
  Spare Devices : 0
 
 
           UUID : 202f047f:650f7c87:050db2d8:98969446
    Number   Major   Minor   RaidDevice State
       0       8        0        0      active sync   /dev/sda
       1       0        0        1      removed

Ами аз имам уж само един контейнер - md0. Не би трябвало проблема ми да е като този от скрипта.

Приемам всякакви предложения и помощ, които включват запазване на информацяита на sda

Здравейте,
Имам два харда в raid1, но единия то тях си замина. Взех нов, но в бързането зарбавих да маркирам стария като фейлнал и да го махна от контейнера . Не знам дали това е от значение, но така е по ръководствата (примерно тук)

След доста ръчкане и тестване, уж билдването започна. При проверка с cat /proc/mdstat си излизаха процентите. Няколко часа по-късно, положението е следното:

Код

GeSHi ():
# cat /proc/mdstat
Personalities : [raid1]
md127 : active raid1 sda[0]
      1953511424 blocks super external:/md0/0 [2/1] [U_]
 
md0 : inactive sdb[1](S) sda[0](S)
      6056 blocks super external:imsm
 
unused devices: <none>
 
 
#mdadm --assemble --force /dev/md0 /dev/sda /dev/sdb
mdadm: /dev/sda is busy - skipping
mdadm: /dev/sdb is busy - skipping
 
# mdadm --examine /dev/sda
/dev/sda:
          Magic : Intel Raid ISM Cfg Sig.
        Version : 1.1.00
    Orig Family : 86e67a30
         Family : 914fca17
     Generation : 007a7b28
     Attributes : All supported
           UUID : 392de428:b7cb9135:70102f5b:d9e480b4
       Checksum : 858f672c correct
    MPB Sectors : 2
          Disks : 2
   RAID Devices : 1
 
  Disk00 Serial : W1F2KMMV
          State : active
             Id : 00000000
    Usable Size : 3907023112 (1863.01 GiB 2000.40 GB)
 
[Volume0]:
           UUID : 202f047f:650f7c87:050db2d8:98969446
     RAID Level : 1 <-- 1
        Members : 2 <-- 2
          Slots : [UU] <-- [U_]
    Failed disk : 1
      This Slot : 0
     Array Size : 3907022848 (1863.01 GiB 2000.40 GB)
   Per Dev Size : 3907023112 (1863.01 GiB 2000.40 GB)
  Sector Offset : 0
    Num Stripes : 15261808
     Chunk Size : 64 KiB <-- 64 KiB
       Reserved : 0
  Migrate State : rebuild
      Map State : normal <-- degraded
     Checkpoint : 5246249 (512)
    Dirty State : dirty
 
  Disk01 Serial : Z4Z3LBC3
          State : active
             Id : 01000000
    Usable Size : 3907023112 (1863.01 GiB 2000.40 GB)
[root@store2 it]# mdadm --examine /dev/sdb
/dev/sdb:
          Magic : Intel Raid ISM Cfg Sig.
        Version : 1.1.00
    Orig Family : 86e67a30
         Family : 914fca17
     Generation : 007a7b28
     Attributes : All supported
           UUID : 392de428:b7cb9135:70102f5b:d9e480b4
       Checksum : 858f672c correct
    MPB Sectors : 2
          Disks : 2
   RAID Devices : 1
 
  Disk01 Serial : Z4Z3LBC3
          State : active
             Id : 01000000
    Usable Size : 3907023112 (1863.01 GiB 2000.40 GB)
 
[Volume0]:
           UUID : 202f047f:650f7c87:050db2d8:98969446
     RAID Level : 1 <-- 1
        Members : 2 <-- 2
          Slots : [UU] <-- [U_]
    Failed disk : 1
      This Slot : 1 (out-of-sync)
     Array Size : 3907022848 (1863.01 GiB 2000.40 GB)
   Per Dev Size : 3907023112 (1863.01 GiB 2000.40 GB)
  Sector Offset : 0
    Num Stripes : 15261808
     Chunk Size : 64 KiB <-- 64 KiB
       Reserved : 0
  Migrate State : rebuild
      Map State : normal <-- degraded
     Checkpoint : 5246249 (512)
    Dirty State : dirty
 
  Disk00 Serial : W1F2KMMV
          State : active
             Id : 00000000
    Usable Size : 3907023112 (1863.01 GiB 2000.40 GB)
 

Аз ли неправя нещо както трябва или... Предполагам не би трябвало да иска рестарт за да се "разпознае" райда?

Някой успя ли да свали тази програма и дали може да я шерне?
Ако има хора които не са в течение, става дума за ето този линк:

https://wikileaks.org/hackingteam/emails/?q=dans.bg&mfrom=&mto=&title=&notitle=&date=&nofrom=root%40hackingteam.it&noto=&count=1000&sort=1#searchresult

ДАНС са смятали да я ползват, но за наша радост, се оказва че:

https://wikileaks.org/hackingteam/emails/emailid/432868

[<sessionState mode="InProc" cookieless="false" timeout="20" sqlConnectionString="ConnectionString" />]

Моите 2 стотинки:

Този линк като че ли по скоро се отнася за аутентикация на уеб потребител (виждам там cookies и forms) в уеб приложение. Ако проблемът ти е с конекцията към оракъл, по скоро ще имаш проблем с някой ODBC dll. Също незнам точно как е в .net (още по малко mono) но за работа с оракъл в много от случаите е нужен oracle client да се инсталира (няколко стотин мегабайта мисля че е пълната версия с всички tool-ове)

Но въпросът ти е много общ, а и аз далеч не съм спеицалист по дот нет и моно. А пробва ли да google-неш грешката.

Приемам пари всякакви
Да, точно за аутентикацията мисля и аз става дума, но не съм се изразил явно правилно.
Имам sqlplus клиент с който успешно се свързвам към базата.

В google проблема се среща на няколко места и или няма отговор или казват да махна въпросния ред:

<sessionState mode="InProc" cookieless="false" timeout="20" sqlConnectionString="ConnectionString" />

който води до тази грешка:

The section <sessionState> can't be defined in this configuration file (the allowed definition context is 'MachineToApplication'). (/var/www/html/xsp/web.config line 41)

Намерих един linux web.config където има описание за <sessionState>

SESSION STATE SETTINGS
          By default ASP.NET uses cookies to identify which requests belong to a particular session.
          If cookies are not available, a session can be tracked by adding a session identifier to the URL.
          To disable cookies, set sessionState cookieless="true".

,но дали го променям или му дам cokieless="true", съобщението за грешка не се променя и винаги казва ще <sessionState> неможе да се дефенира в конфига.

Съответно, ако го махна, новата грешка която се появява е:

The section <authentication> can't be defined in this configuration file (the allowed definition context is 'MachineToApplication'). (/var/www/html/xsp/web.config line 60)

реда гласи:

               

                <!--
            The <authentication> section enables configuration
            of the security authentication mode used by
            ASP.NET to identify an incoming user.
        -->
                <authentication mode="Windows" />

За нея намерих инфо тук и пича (прилича ми на индиец ) явно е намерил решение съответно от този линк, но не е писал как точно е оправил проблема.


----------------EDIT----------------

Намерих решение на този проблем:

This is expected behaviour. You must run xsp in the root of your web application or specific a path to be root.

For example...

xsp2 --root /var/www/blogengine

Опитвам се да прехвърля един сайт aspx на mono, но запецнах до следната грешка:

The section <sessionState> can't be defined in this configuration file (the allowed definition context is 'MachineToApplication').

След ровене насам и натам, разбрах че проблема е в автентикацията към oracle. Опитах какво ли не, свързано с аuthentication mode (дори и None), но или аз не го правя както трябва или... незнам и аз вече.

Някой пускал ли е подобно нещо, да даде едно рамо?